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

本文是由他最近解决的一个 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 链定位这个问题。