本文是由最近一个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?
- 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链:
[[email protected] ~]# 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链:
[[email protected] ~]# 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链:
[[email protected] ~]# 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链:
[[email protected] ~]# 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链:
[[email protected] ~]# 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. */
最后看下,如果以上规则都不匹配,做的动作:
[[email protected] ~]# 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协议规则。
[[email protected] ~]# 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上加入规则:
在控制节点上看到规则已经生成:
[[email protected] ~]# 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)。
[[email protected] ~]# 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