带着问题了解Openstack Neutron安全组

本文是由最近一个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链:

[[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

时间: 2024-10-10 14:15:03

带着问题了解Openstack Neutron安全组的相关文章

openstack neutron L3 HA

作者:Liping Mao  发表于:2014-08-20 版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明 最近Assaf Muller写了一篇关于Neutron L3 HA的文章很不错. 建议看原文,地址如下: http://assafmuller.wordpress.com/category/ml2/ 大致翻译如下: L3 Agent Low Availability(L3 agent的低可用性) 目前,在Openstack中,你只能用多个网络节点达到

[转]OpenStack Neutron解析

1.为什么还需要linux bridge的部署方式? 2.哪一个网桥起着交换机的作用? 3.neutron如何实现私有网络的隔离 ================================================== 很久之前写了一篇关于OpenStack Neutron解析的文章,那时只是粗略的写了一下把Neutorn的整体架构分析了一下,后来一直忙于其他事情,也就忘了去详细分析一下Neutron的架构.这次这篇算是完成未完之事,同时也是对之前的一个知识的总结及恢复. OpenS

[转]OpenStack Neutron运行机制解析概要

转载自:http://panpei.net.cn/2013/12/04/openstack-neutron-mechanism-introduce/ 自从开学以来,玩OpenStack也已经3个月了,这段时间主要把精力投在了OpenStack的安装部署和网络组件Neutron的研究上了.这期间零零散散在安装部署和Neutron运作原理上来回切换,有点在实践中学习的味道,虽然在安装部署的过程遇到了不少的问题,也一一都给解决了.然而,总是觉得对于Neutron的机制理解的还是不够透彻.前一阵子刚刚部

OpenStack neutron vlan 模式下的网络包流向

时间:2015-01-15 18:09:41 1.什么是Neutron? Neutron是OpenStack的network project ,是NaaS(networking-as-a-service)专题,负责网络虚拟化,开始于OpenStack的Folsom版,取名为Quantum,在Havana版本改名为Neutron.Neutron并非提供特定的网络功能,而是为了管理网络,提供网络服务,你可以使用不同厂商开发的插件,在同一个架构中可以同时拥有多种网络模式(vlan.gre.vxlan等

OpenStack Neutron L3层高可靠

英文地址:http://assafmuller.com/2014/08/16/layer-3-high-availability/ L3层Agent的低可靠解决方案 当前,你可以通过多网络节点的方式解决负载均衡,但是这并非高可靠和冗余的解决方案.假设你有三个网络节点,创建新的路由,会自动的规划和分布在这三个网络节点上.但是,如果一个节点坏掉,所有路由将无法提供服务,路由转发也无法正常进行.Neutron,在IceHouse版本中,没有提供任何内置的解决方案. DHCP Agent的高可靠的变通之

Openstack Neutron : 安全

目录 - iptable:起源 - tables - chains - rules - 方向 - Security group 安全组: - Firewall 防火墙: - 更高的安全 - 无处安放的安全 - 公共安全 当业务从传统环境迁移到云上之后,安全问题变得更为复杂了.Neutron包含了2大安全组件:安全组(security group).防火墙(firewall).安全组解决的是虚拟机东西向的访问控制问题,而防火墙解决的则是南北向的访问控制问题. 两者都只解决了网络层和传输层的访问控制

怎样写 OpenStack Neutron 的 Extension (四)

上文说到需要在 /neutronclient/v2_0/myextension/extension.py 中分别定义五个 class:List/Show/Create/Delete/UpdateExtension.具体形式如下: import argparse import logging from neutronclient.neutron import v2_0 as neutronV20 from neutronclient.openstack.common.gettextutils im

如何区分 OpenStack Neutron Extension 和 Plugin

Neutron 里面的 extension 和 plugin 是非常相似的两个概念,我花了好久才貌似搞懂了两者的区别,还不一定完全正确. 在OpenStack 的官网wiki中,可以找到它们两个的定义: Plugin: Neutron exposes a logical API to define network connectivity between devices from other OpenStack services (e.g., vNICs from Nova VMs). The

深入浅出新一代云网络——VPC中的那些功能与基于OpenStack Neutron的实现(二)

在VPC功能实现第一篇中,简单介绍了一下VPC网络对租户间隔离能力的提升以及基于路由提供的一系列网络功能.在这一篇中,将继续介绍VPC网络中十分重要的一个内容:网络带宽的控制,共享以及分离. 首先是对第一篇中,端口转发功能的样例代码,all-in-one http service 风格的实现. 核心功能: find_router_ip = "ip netns exec qrouter-{router_id} ifconfig |grep -A1 qg- | grep inet | awk '{{