本文是由他最近解决的一个Openstack Neutron安全组问题所触发而写，让我们跟随作者的思路一起来了解Neutron Security Group和一般网络问题的解决思路吧。

前言

本文主要用来记录最近解决的一个Openstack Neutron安全组的问题。在为业务部门创建lvs服务时，Linux Director与Real Server间无法进行正常的通讯，Real Server是由Hulk云平台创建的Openstack虚拟机。

网络问题排查，按照『确定网络结构 - 抓包定位 - 分析定位问题 - 纠正网络部署 - 单元测试 - 完整测试 -（推入生产）- 回归测试 - 总结回顾』的思路来就基本搞定了。

1 确定网络结构

遇到网络问题，首先考虑数据包在全流程中drop的位置，所以，首先我们要熟知Openstack Neutron网络的整个架构。为了重点讲述Openstack Neutron网络及安全组，我们假设Linux Director和Real Server虚机所在的物理主机之间的网络可达。如下图是Openstack Neutron网络数据面的基本架构。

看下这个架构图，首先遇到一个特殊之处，我们暂且花点时间看一下： br-ethx与br-int是OVS创建的OVS Bridge，qbr-XXX是Linux Bridge，为什么不把虚机的Tap设备直接挂到OVS Bridge的br-int上，而在br-int和Tap设备间加个Linux Bridge qbr-XXX？

1.Openstack Neutron需要在宿主机上执行一定的安全策略；
2.Hulk平台使用的ovs版本是2.3.1，该版本尚未完全支持安全策略的内核模块实施部分：netfilter模块；
3.增加一个中间层Linux bridge可以解决网络策略配置。

Openstack Neutron网络各设备及配置请参考这里。

接下来我们进入探索之旅。

2 抓包定位

在物理机和虚机上抓包：在客户端发送请求数据包后，分别在ABCDEFG七个点中抓包：

tcpdump -i xxx -nv | grep ipip

其中，在CDEFG 5个点都能抓到数据包，在AB两点没有抓到。

3 分析定位问题

问题出现在BC两点之间，即Linux bridge与Tap设备之间。Openstack Neutron在这两点之间利用iptables做安全策略，那么是如何实现的，为什么会丢包？反过来想，既然ssh能够连接上虚机，说明TCP数据包正常，更确信iptables安全策略存在问题。

下面，我们先了解下Openstack Neutron如何实现安全组策略。

4 Neutron安全组的iptables规则

Neutron L2 Agent承担使用iptables维护链和规则的任务。它为虚机的每块网卡的tap设备建立 i（进）、o（出）和s（防IP欺骗）链和规则，来实现：

1.prepares, updates, removes firewall filters （准备、更新和删除防火墙过滤器）
2.drops all packets by default （默认丢弃所有包）
3.prevents IP spoofing based on port’s mac address (compatible with allowed_address_pairs extension) （防IP欺骗）
4.allows incoming DHCP and ICMPv6 RA （允许进入虚机的DHCP包和ICMPV6 RA）
5.blocks outgoing DHCP （禁止出虚机的DHCP包）
6.drops INVALID packets （丢弃无效状态的包）
7.allows stateful, established connections （允许有状态的并且已建立的连接，比如允许进来的ICMP的时候，从外面ping虚机时虚机的响应包是可以返回的）
8.converts security group rules to iptables rules (IPv4, IPv6, TCP, UDP, ICMP, ICMPv6) （将用户配置的规则转化为iptables规则）
9.multiple TCP/UDP ports per iptables rule using multiport module
支持 IPV4 和 IPV6

来看看Neutron为了实现这些功能添加的iptables链：

[root@w-openstack32 ~]# iptables -S | grep neutron
-N neutron-filter-top
-N neutron-openvswi-FORWARD             #neutorn定义的FORWARD链
-N neutron-openvswi-INPUT               #Neutron定义的INPUT链
-N neutron-openvswi-OUTPUT              #Neutron定义的OUTPUT链 
-N neutron-openvswi-ibddxxxxc-b         #处理进入该虚机的网络包
-N neutron-openvswi-local
-N neutron-openvswi-obddxxxxc-b         #处理出该虚机的网络包
-N neutron-openvswi-sbddxxxxc-b         #处理出该虚机的网络包的防IP欺骗
-N neutron-openvswi-sg-chain    
-N neutron-openvswi-sg-fallback
-A INPUT -j neutron-openvswi-INPUT      #将INPUT链转到neutron的INPUT链
-A FORWARD -j neutron-filter-top
-A FORWARD -j neutron-openvswi-FORWARD  #将FORWARD链转到neutorn的forward链
-A OUTPUT -j neutron-filter-top
-A OUTPUT -j neutron-openvswi-OUTPUT    #将OUTPUT链转到neutron的output链
-A neutron-filter-top -j neutron-openvswi-local

这些链之间的关系：

当前由于iptables主要做控制qbr桥在虚机和br-int之间转发的网络帧，Bridge代码应该是用filter表的FORWARD链来处理这些网络帧。

下面我们逐步跟踪FORWARD链，来找到neutron-openvswi-ixxxxx链定位这个问题。

创作场景

带着问题了解 Openstack Neutron 安全组（上）