openstack 安全组范围 openstack查看安全组

转载

mob64ca1411a6fc 2024-03-13 14:51:38

文章标签 openstack 安全组范围 TCP IP 抓包 文章分类 OpenStack 云计算

女主宣言

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

前言

本文主要用来记录最近解决的一个Openstack Neutron安全组的问题。在为业务部门创建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？

openstack 安全组范围 openstack查看安全组_TCP

Openstack Neutron需要在宿主机上执行一定的安全策略；
Hulk平台使用的ovs版本是2.3.1，该版本尚未完全支持安全策略的内核模块实施部分：netfilter模块；
增加一个中间层Linux bridge可以解决网络策略配置。

Openstack Neutron网络各设备及配置请参考这里。

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

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

抓包定位

在物理机和虚机上抓包：在客户端发送请求数据包后，分别在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

这些链之间的关系：

openstack 安全组范围 openstack查看安全组_IP_02

当前由于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. */

Neutron安全组白名单机制

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

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

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

openstack 安全组范围 openstack查看安全组_openstack 安全组范围_03

确认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 安全组范围 openstack查看安全组_TCP_04

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

openstack 安全组范围 openstack查看安全组_openstack 安全组范围_05

单元测试

再去虚机抓包，客户端发包通信接收到应答包，并且在虚机上抓到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的原理。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。