带着问题了解Openstack Neutron安全组

女主宣言

本文出自于ADDOPS团队，该文章作者李文新是360 HULK云平台容器化及虚拟化平台运维开发工程师，负责网络模块的设计与开发。本文是由他最近解决的一个Openstack Neutron安全组问题所触发而写，让我们跟随作者的思路一起来了解Neutron Security Group和一般网络问题的解决思路吧。

PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！

前言

本文主要用来记录最近解决的一个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网络各设备及配置请参考这里。

(http://www.sdnlab.com/13000.html)

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

2

抓包定位

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

tcpdump -i xxx -nv | grep ipip

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

3