OpenStack security Group and Conntrack profile _openstack

Security groups in OpenStack implement communication between trusted virtual machines, and the same security policy is used for virtual machines that bind to the same security group. The security group is scoped to the virtual machine and more specifically to the port on the virtual machine than to the network. The security group in OpenStack is based on iptables implementation, and because the current openvswitch (OVS) cannot use Iptables rule, the virtual machine first connects to Linux Bridge and then connects to the OvS. Reference link [1].

When using iptables, the status of the message can be categorized into four kinds: NEW establisedrelated invaild. NetFilter is the Conntrack implementation of the connection tracking. Conntrack is a Linux kernel module that uses Conntrack entry to record the state information of the connection, which can be referred to [2].

1. SG without Conntrack-tool

Figure 1

Neutron initially implemented the security group functionality without considering the handling of conntrack, causing some problems. Figure 1 Virtual Machine vm1 (1.1.1.8) vm2 (1.1.1.9) belongs to the same subnet, is located at the same compute node, is bound to the default security group, and performs a vm1 ping vm2 to ping. The ingress rule in the default security group is removed to retain the egress rule, and the VM1 ping vm2 has not been interrupted [3].

The reason for this is that the ICMP message arrives at the VM2 connected Linux bridge and enters the iptables processing stage. VM2 in Iptables (reference [4]) has a rule for-mstate--state related,established-m comment-j return (default rule), which indicates that the state is RELATED Established connections can flow into the vm2.

Since the ingress rule was removed, neutron did not perform any action on the Conntrack and no action was performed to stop the VM1 ping vm2 and the corresponding Conntrack entry persisted and did not expire. So even the deleted ingress rule traffic in the default security group is still not interrupted.

$ sudo conntrack-l-p ICMP

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=11521 src=1.1.1.9dst=1.1.1.8 type=0 code=0 id=11521 mark=0 use=1

Conntrack v1.4.1 (conntrack-tools): 1 flowentries have been.

If you re performing vm1 Ping vm2, you will not be able to ping this time. This message will still go into iptables because the default security group has removed the ingress rule, so the condition that the ICMP message can flow into the vm2 is still to be able to satisfy the state related,established.

But this time the ICMP message is considered a new state. View Conntrack found that although the old entry (ID 11521) still exists, the process of pinging is considered a new connection, corresponding to the new entry (ID 12033), unreplied indicates that the connection has not yet been established.

$ sudo conntrack-l-p ICMP

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=11521 src=1.1.1.9dst=1.1.1.8 type=0 code=0 id=11521 mark=0 use=1

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=12033 [unreplied]src=1.1.1.9 dst=1.1.1.8 type=0 code=0 id=12033 Mark =0 use=1

Conntrack v1.4.1 (conntrack-tools): 2 flowentries have been.

In addition, there is no issue of tenant isolation for conntrack processing: Tenant 1 created virtual machine vm1 (1.1.1.8) vm2 (1.1.1.9), as shown in Figure 1, tenant 2 creates the same IP virtual machine vm3 (1.1.1.8) vm4 (1.1.1.9) and vm1/ 2/3/4 are all in the same compute node, the Conntrack entry generated by VM1/2 communication will have an effect on communication between VM3/4, refer to [5].

2. SG with Conntrack-tool

The related bugs were raised in 2014, and until August 2015 these problems were resolved. The Stableliberty version uses Conntrack tool to implement Conntrackentry management.

Still using the environment shown in Figure 1, the default security group ingress and egress rules all exist to perform vm1 ping vm2 and view Conntrack:

$ sudo conntrack-l-p ICMP

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=10753 src=1.1.1.9dst=1.1.1.8 type=0 code=0 id=10753 mark=0 zone=2use =1

Conntrack v1.4.1 (conntrack-tools): 1 flowentries have been.

The ingress rule is deleted at this time, and the communication is immediately interrupted because the above Conntrack entry is deleted immediately.

In addition, the above Conntrack entry adds a zone property that is designed to avoid the tenant isolation problem that occurs in [5]. On each compute node, the network to which the virtual machine belongs has a one by one correspondence with the local VLAN, and the zone value is set to the native VLAN, which enables Conntrack entry to be isolated locally.

Reference Links:

[1]https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/4/html/ Configuration_reference_guide/section_networking-scenarios.html

[2]http://www.iptables.info/en/connection-state.html

[3]https://bugs.launchpad.net/neutron/+bug/1335375

[4]http://blog.csdn.net/yeasy/article/details/21612151?utm_source=tuicool&utm_medium=referral

[5]https://bugs.launchpad.net/neutron/+bug/1359523