openstack网络问题

openstack train
openstack里的VM，当作为网络代理设备进行网络包的代理转发，类似于网关的角色，可能会遇到问题。
原因是作为代理角色，当收到请求并进行代理转发处理，处理完成后在回包时，包里面的源MAC和IP是不匹配的。
也就是说，二层的源MAC，是自己的；但三层的源IP，是请求者要访问的目标IP，而不是自己的。（可以用tcpdump加-e看到MAC）
这种情况，对于网络代理的角色，是很常见的。但是因为openstack的默认网络规则，导致无法回包。

-N neutron-openvswi-s353171f1-5
-A neutron-openvswi-o353171f1-5 -j neutron-openvswi-s353171f1-5
-A neutron-openvswi-s353171f1-5 -s 10.0.0.44/32 -m mac --mac-source FA:16:3E:47:35:E1 -m comment --comment "Allow traffic from defined IP/MAC pairs." -j RETURN
-A neutron-openvswi-s353171f1-5 -m comment --comment "Drop traffic without an IP/MAC allow rule." -j DROP

因为这个chain里面的规则的存在，VM出去的包，源IP和MAC必须要匹配到VM自己的信息，才可以真正出的去。

这是一个在openstack主机上的iptables规则。chain的名称中，包含了353171f1-5?（?是被截断的那个字符），这串字符，是在VM对应的tap接口的名称、tap所在的linux bridge的名称、bridge上另一个连接ovs的接口的名称，里面都包含的。所以这个特征字符的一致性，代表了他们之前存在某种联系。

打掉对源IP的绑定：

iptables -R neutron-openvswi-s353171f1-5 1 -s 0.0.0.0/0 -m mac --mac-source FA:16:3E:47:35:E1 -m comment --comment "Allow traffic from any IP with specified MAC address." -j RETURN

只能通过命令来，通过安全组无法实现。并且这个潜在的规则，在安全组的默认规则里并没有体现出来。而打掉对源IP的绑定，似乎也无法通过安全组的设置来实现。

以上都是在主机里。不涉及新增的网络命名空间。