带着问题了解Openstack Neutron安全组

最新推荐文章于 2019-09-02 21:47:29 发布

weixin_30610755

最新推荐文章于 2019-09-02 21:47:29 发布

阅读量212

点赞数

原文链接：http://www.cnblogs.com/wenxinlee/p/7851078.html

版权

本文是由最近一个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网络数据面的基本架构。

neutron计算节点网络全局图 neutron计算节点网络组成

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

Openstack Neutron需要在宿主机上执行一定的安全策略；
Hulk平台使用的ovs版本是2.3.1，该版本尚未完全支持安全策略的内核模块实施部分：netfilter模块；
增加一个中间层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

这些链之间的关系：
neutron实现安全组添加的iptables链

当前由于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上加入规则：

Openstack Neutron安全组

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

[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的原理。

转载于:https://www.cnblogs.com/wenxinlee/p/7851078.html

weixin_30610755

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
带着问题了解Openstack Neutron安全组

本文是由最近一个Openstack Neutron安全组的问题所触发而写。希望之后借此机会深入探讨一下iptables和netfilter相关用法、原理等。本节先看看网络问题的解决思路以及Openstack Neutron安全组，之后再开篇细讲背后的网络内核netfilter。问题简述公司系统部同事为业务部门创建lvs服务时，Linux Director与Real Server间无法进行正...
复制链接

扫一扫