码迷,mamicode.com
首页 > 其他好文 > 详细

带着问题了解Openstack Neutron安全组

时间:2018-03-08 14:43:52      阅读:208      评论:0      收藏:0      [点我收藏+]

标签:不为   主机   为什么   extension   table   min   存在   pdu   ref   

本文是由最近一个Openstack Neutron安全组的问题所触发而写。希望之后借此机会深入探讨一下iptables和netfilter相关用法、原理等。
本节先看看网络问题的解决思路以及Openstack Neutron安全组,之后再开篇细讲背后的网络内核netfilter。

问题简述

公司系统部同事为业务部门创建lvs服务时,Linux Director与Real Server间无法进行正常的通讯,Real Server是由Hulk平台创建的openstack虚拟机。
网络问题排查,按照“确定网络结构 - 抓包定位 - 分析定位问题 - 纠正网络部署 - 单元测试 - 完整测试 -(推入生产)- 回归测试 - 总结回顾”的思路来 就基本搞定了。

确定网络结构

遇到网络问题,首先考虑数据包在全流程中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网络各设备及配置请参考这里

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

抓包定位

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

tcpdump -i xxx -nv | grep ipip

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

分析定位问题

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

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

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

链跟踪,定位位置

首先,查看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. */

Openstack Neutron安全组白名单机制

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

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

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

[root@w-openstack01 ~]# neutron security-group-list
+--------------------------------------+---------+------------------------------------------------+
| id                                   | name    | security_group_rules                           |
+--------------------------------------+---------+------------------------------------------------+
| 15b463bf-f232-489e-90b2-c08699454b29 | default |                                                |
+--------------------------------------+---------+------------------------------------------------+

确认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)  */
...

加入规则,纠正网络

在Openstack Neutron安全组dashboard上加入规则:

技术分享图片

在控制节点上看到规则已经生成:

[root@w-openstack01 ~]# neutron security-group-list
+--------------------------------------+---------+------------------------------------------------+
| id                                   | name    | security_group_rules                           |
+--------------------------------------+---------+------------------------------------------------+
| 15b463bf-f232-489e-90b2-c08699454b29 | default | ingress, IPv4, 4, remote_ip_prefix: 0.0.0.0/0 |
+--------------------------------------+---------+------------------------------------------------+

单元测试

再去虚机抓包,客户端发包通信接收到应答包,并且在虚机上抓到IPIP数据包。同时用命令行查看iptables,已有数据包匹配并执行(prot为4的pkts不为0)。

[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. */
   12266  7040888 RETURN     4    --  *      *       0.0.0.0/0            0.0.0.0/0
       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. */

在虚机上抓包,没有看到其他类型数据包进入:

tcpdump -i any \(not icmp\) and \(not udp\) and \(not tcp\) and \(not arp\)

推入生产,回归测试

经验证,和测试环境效果一致,done。

总结

通过问题的探索,我们了解Openstack Neutron的安全组策略相关知识了,也对Neutron网络数据面的网络拓扑架构有了基本的认识。之后,我会结合源码展开谈谈iptables模式匹配与执行,以及iptables的高级用法和原理,以及部分netfilter的原理。

带着问题了解Openstack Neutron安全组

标签:不为   主机   为什么   extension   table   min   存在   pdu   ref   

原文地址:https://www.cnblogs.com/wenxinlee/p/7851078.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!