专栏名称: HULK一线技术杂谈
HULK是360的私有云平台,丰富的一线实战经验,为你带来最有料的技术分享
目录
相关文章推荐
传媒招聘那些事儿  ·  爱奇艺:资深达人运营(剧情/搞笑方向) ·  3 天前  
传媒招聘那些事儿  ·  网易:高级/资深渠道运营 ·  3 天前  
传媒招聘那些事儿  ·  淘天集团:淘宝秒杀-母婴/美妆行业商品运营 ·  2 天前  
传媒招聘那些事儿  ·  【职业咨询/导师答疑】1V1模拟面试/语音答 ... ·  3 天前  
51好读  ›  专栏  ›  HULK一线技术杂谈

带着问题了解Openstack Neutron安全组

HULK一线技术杂谈  · 公众号  ·  · 2017-11-09 18:56

正文

女主宣言

本文出自于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

分析定位问题

问题出现在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链定位这个问题。


5

链跟踪,定位位置

首先,查看FORWARD链:

[root@w-openstack32 ~]# iptables -nxvL FORWARD

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

pkts      bytes target     prot opt in     out     source               destination

46935472750 20715430397978 neutron-filter-top  all  --  *      *       0.0.0.0/0            0.0.0.0/0

46935472750 20715430397978 neutron-openvswi-FORWARD  all  --  *      *       0.0.0.0/0            0.0.0.0/0


往下走,跟踪neutron-openvswi-FORWARD链:

[root@w-openstack32 ~]# iptables -nxvL neutron-openvswi-FORWARD

Chain neutron-openvswi-FORWARD (1 references)

pkts      bytes target     prot opt in     out     source               destination

46934035761 20714724813160 neutron-openvswi-scope  all  --  *      *       0.0.0.0/0            0.0.0.0/0

459609600 121602465610 neutron-openvswi-sg-chain  all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-out tapbddxxxxc-bd --physdev-is-bridged /* Direct traffic from the VM interface to the security group chain. */

418512415 87324679449 neutron-openvswi-sg-chain  all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in tapbddxxxxc-bd --physdev-is-bridged /* Direct traffic from the VM interface to the security group chain. */


继续往下走,跟踪neutron-openvswi-sg-chain链:

[root@w-openstack32 ~]# iptables -nxvL neutron-openvswi-sg-chain

Chain neutron-openvswi-sg-chain (10 references)

pkts      bytes target     prot opt in     out     source               destination

459619285 121606141606 neutron-openvswi-ibddxxxxc-b  all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-out tapbddxxxxc-bd --physdev-is-bridged /* Jump to the VM specific chain. */

418522179 87328347603 neutron-openvswi-obddxxxxc-b  all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in tapbddxxxxc-bd --physdev-is-bridged /* Jump to the VM specific chain. */

46927558621 20715211464005 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0


往下走,跟踪进入neutron-openvswi-ibddxxxxc-b链:

[root@w-openstack32 ~]# iptables -nxvL neutron-openvswi-ibddxxxxc-b

Chain neutron-openvswi-ibddxxxxc-b (1 references)

pkts      bytes target     prot opt in     out     source               destination

428583997 119531816501 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */

0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID /* Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack. */

1937647 124006974 neutron-openvswi-sg-fallback  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Send unmatched traffic to the fallback chain. */


最后看下,如果以上规则都不匹配,做的动作:

[root@w-openstack32 ~]# iptables -nxvL neutron-openvswi-sg-fallback

Chain neutron-openvswi-sg-fallback (10 references)

pkts      bytes target     prot opt in     out     source               destination

9841017 629783588 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Default drop rule for unmatched traffic. */


6

Neutron安全组白名单机制

Openstack Neutron安全组使用白名单机制,此时网络的访问能力 = 用户自定义的规则允许的能力。如果这些规则都不匹配,没看错,是drop掉该数据包。


可以通过上边的iptables命令看到,安全组没有放开IPIP协议的规则,所以数据包没进到虚机中。


控制节点上再确认下安全组策略,的确没有IPIP协议规则。



7

确认IPIP协议号

查看kernel源码中头文件include/uapi/linux/in.h,可以看到IPIP协议号是4;

/* Standard well-defined IP protocols.  */

enum {

IPPROTO_IP = 0,   /* Dummy protocol for TCP   */

IPPROTO_ICMP = 1,   /* Internet Control Message Protocol  */

IPPROTO_IGMP = 2,   /* Internet Group Management Protocol */

IPPROTO_IPIP = 4,   /* IPIP tunnels (older KA9Q tunnels use 94) */

IPPROTO_TCP = 6,    /* Transmission Control Protocol  */

IPPROTO_EGP = 8,    /* Exterior Gateway Protocol    */

IPPROTO_PUP = 12,   /* PUP protocol       */

IPPROTO_UDP = 17,   /* User Datagram Protocol   */

IPPROTO_IDP = 22,   /* XNS IDP protocol     */

IPPROTO_DCCP = 33,    /* Datagram Congestion Control Protocol */

IPPROTO_RSVP = 46,    /* RSVP protocol      */

IPPROTO_GRE = 47,   /* Cisco GRE tunnels (rfc 1701,1702)  */

...








请到「今天看啥」查看全文