Analysis of firewall rules in openstack

Last week, I spent a few days studying the openstack Security Group firewall rules and summarized the results of last week.

 

1. Introduce my environment.

Operating System: rhel6.4 + openstack official Kernel

Openstack version: Havana

Network Mode: ml2 + linuxbridge

Tenant Network: VLAN

Ii. iptables Flow Direction

Input

Neutron-linuxbri-Input

Neutron-linuxbri-o45d1d6e0-d

Neutron-linuxbri-s45d1d6e0-d

Neutron-linuxbri-SG-Fallback

Output

Neutron-filter-top

Neutron-linuxbri-Local

Neutron-linuxbri-Output

Forword

Neutron-filter-top

Neutron-linuxbri-Local

Neutron-linuxbri-forward

Neutron-linuxbri-SG-chain =>

A => neutron-linuxbri-i45d1d6e0-d => B

 

A => neutron-linuxbri-o45d1d6e0-d

Neutron-linuxbri-s45d1d6e0-d => B

 

B => neutron-linuxbri-SG-Fallback

This flow is too messy. I will organize it into an image in another day.

Here, only the flow of Layer 2 data packets is analyzed.

Iii. Summary

1. What actually works is:

Neutron-linuxbri-i45d1d6e0-d

Neutron-linuxbri-o45d1d6e0-d

Neutron-linuxbri-s45d1d6e0-d

2, neutron-linuxbri-i45d1d6e0-d this is to enter the virtual machine flow control, according to the default security group of openstack, the network of different tenants under the same network is not accessible.

3, neutron-linuxbri-s45d1d6e0-d this is to do the IP and Mac binding function.

4, neutron-linuxbri-o45d1d6e0-d this is done out of virtual machine flow control, according to the default openstack security group, all through.

5. The naming rules for these binchains are as follows: the first 16 of the l2agent names used are-data flow [I/O/S]-the first 11 bits of the uuid port.

This article is from the killingwolf blog, please be sure to keep this source http://killingwolf.blog.51cto.com/3309954/1440644

Analysis of firewall rules in openstack