安保组成功原理 深化浅出解析 OpenStack

1、iptables简介

1.1 iptables概述

在引见OpenStack安保组前先便捷引见下iptables，其实iptables只是一个用户空间的程序，真正干活的其实是Linux内核netfilter，经过iptables创立新规定，其实就是在netfilter中拔出一个hook，从而成功修负数据包、控制数据包流向等，对iptables经常使用方法不相熟的可以参考图文并茂了解iptables[1].

便捷地说，iptables就是经过一系列规定条件婚配执行指定的举措，因此一条规定就是由条件+举措导致，条件比如源IP地址、四层协定、端口等，举措如拒绝、经过、摈弃、修正包等，举措通常经过-j参数指定。

比如拒绝192.168.1.2访问指标22端口，只要要参与如下iptables规定：

如上：

1.2 iptables婚配条件

除了以上的-s、-p、--dport等参数作为婚配条件外，iptables还支持如-d婚配指标IP地址，-i、-o区分指定从哪个网卡进入的以及从哪个网卡出去的。当然这些婚配条件还不够，甚至都不支持婚配MAC地址。iptables为了满足不同的需求，经过裁减模块支持更多的婚配条件，关键分为如下两类：

不同的裁减模块支持不同的参数，比如mac模块，支持--mac-source参数。

经常使用裁减模块必需经过-m参数加载，之前我不时以为-m是--module的缩写，看iptables的man手册才发现其实是--match的缩写，不过咱们只要要知道是加载裁减模块的性能就可以了。

比如咱们不准许MAC地址为FA:16:3E:A0:59:BA经过，经过如下规定性能：

iptables的裁减模块十分多，详细可以经过man iptables-extensions命令检查，不过OpenStack安保组用到的并不多:

1.3 iptables执执行作

前面提到iptables经过-j指定执行的举措(target)，iptables经常出现的target如下:

当然还有成功NAT的SNAT、MASQUERADE、DNAT，由于安保组成功触及不到，因此不做详细引见，另外还有RETURN以及指向另一个链的举措，等前面引见了子链再探讨。

举措通常都是短路的，也就是说一旦婚配规定并执执行作，就不会继续往后去婚配该链的其余规定了，当然这并不是相对的，比如LOG举措就是例外，执行该举措后会继续婚配下一条规定。

1.4 iptables链

前面提到iptables一共有5条链，并且链可以以为是一个单向链表，疑问来了，当接纳到一个新包，究竟是如何婚配规定的。这里我间接援用图文并茂了解iptables的图[1]:

(1) 数据包首先抵达PREROUTING链，而后依照raw、mangle、nat的顺序婚配执行定义在PREROUTING的规定。

(2)接上去经过路由判别，假设包是发给自己的则流向INPUT链，而后由INPUT链发给用户空间进程处置。假设不是发给自己的包，则流向FORWARD表，雷同依照raw-> mangle -> nat -> filter表依次婚配执行链上的规定。

(3) 同理，ONPUT链、POSTROUTING链，包流向方向，间接看图，十明显晰，这里不再赘述。

前面提到每条链上都可以拔出规定，须要留意的是这些规定是有顺序的，iptables每次婚配时都是从第一条规定开局婚配，依次婚配下一条，一旦婚配其中一条规定，则执行对应的举措。

必需有人会不懂，假设这条链上的规定都不婚配该怎样办，答案是取决于该链的自动战略(policy)。假设该战略是DROP，则最后没有婚配的包都将摈弃，即该链时白名单列表。假设自动战略是ACCEPT，则最后没有婚配的包都会经过,即该链时黑名单列表。当然通常policy都设置为ACCEPT，由于性能为DROP太风险了，比如清空规定立马就相当于全不通了，假设你经过SSH衔接的主机，则立刻终止衔接了，不得不经过vnc或许带外console衔接重置，所以不倡导修正policy。

经过如下命令检查filter表各个链的自动战略:

假设一条链规定特意多且复杂，治理起来十分费事，因此很有必要对链依据性能分组。iptables经过自定义链成功。用户可以经过iptables -Nname创立一个新链，而后和内置链一样可以往新链中参与规定。然而须要留意的是，自定义链不能独立存在，必需挂在内置5条链上方，即必需是内置链的子链。

前面1.3节提了下-j可以指定一条新链，这里的新链即子链，即iptables是经过-j把子链挂到某个规定上方。比如创立一个准许SSH访问的白名单列表，可以创立一个新的子链，SSH相关的战略都放在这个新链中:

以上第二条命令示意将一切访问本机端口22的包都放到SSH_Access_List这条子链上处置，而后这条子链上参与了许多白名单规定，由于进到这个子链的必定是指标22端口的，因此规定毋庸要在指定--dport参数，最后一个DROP示意不在白名单列表中的包间接丢掉。

须要留意的是白名单规定中的举措不是ACCEPT而是RETURN，这两者有什么区别呢?ACCEPT示意准许包间接经过INPUT，不须要再婚配INPUT的其余规定。而RETURN则示意只是不须要再婚配该子链下的前面规定，但须要前往到该子链的母链的规定或许子链继续婚配，能不能经过INPUT关卡取决于前面的规定。

另外须要留意的是，前面提到内置的5条链可以性能policy，当一切规定都不婚配时，经常使用policy对包启动处置。然而，自定义链是不支持policy的，更确切的说，不支持设置policy，由于自定义链的policy只能是RETURN，即假设子链的规定都不婚配，则必定会前往到母链中继续婚配。

1.5 iptables总结

本小节便捷引见了iptables的性能和用法，总结如下：

1、iptables经过规定婚配选择包的去向，规定由婚配条件+举措导致，规定经过-I、-A拔出。

2、五链五表，五链为PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING，五表为raw、mangle、nat、filter、security。链、表、规定都是有顺序的。

3、当链中的一切规定都不婚配时，iptables会依据链设置的自动战略policy处置包，经过policy设置为ACCEPT，不倡导性能为DROP。

4、可以创立子链挂在内置链中，子链的policy为RETURN，不支持性能。

5、婚配条件包含基本婚配条件以及裁减模块提供的裁减婚配条件，裁减婚配条件经过-m参数加载，须要记住的裁减模块为comment、tcp、udp、icmp、mac、state、physdev、set。

6、经常出现的iptables举措(target)为ACCEPT、DROP、RETURN、LOG以及跳转到子链。

2、OpenStack安保组简介

2.1 Neutron安保组 VS Nova安保组

OpenStack安保组最开局是经过Nova治理及性能的，引入Neutron后，新OpenStack安保组则是经过Neutron治理，并且关联的对象也不是虚构机，而是port。咱们在页面上把虚构机加到某个安保组，其实是把虚构机的port关联到安保组中。

由于历史的要素，或许还有些版本的Nova依然保管着对安保组规定的操作API，不过不倡导经常使用，倡导经过Neutron启动安保组规定治理。

2.2 security group VS firewall

很多刚开局接触OpenStack的用户分不分明安保组(securitygroup)和防火墙(firewall)的区别，由于二者都是做网络访问控制的，并且社区都是基于iptables成功的。其实二者的区别还是比拟大的:

2.3 安保组用法引见

前面引见了安保组，安保组其实就是一个汇合，须要把安保组规定放到这个汇合才无心义。

Neutron经过security-group-create子命令创立安保组，参数只要一个name，即安保组称号:

不过Neutron创立的新安保组并不是一个空规定安保组，而是会智能参与两条自动规定:

即制止一切的流量访问，准许一切的流量出去。

创立了安保组后，就可以往安保组外面加规定了。Neutron经过security-group-rule-create子命令创立，触及的参数如下：

创立一条安保组规定，只准许192.168.4.5访问虚构机SSH 22端口：

须要留意的是创立安保组和安保组规定只是一个逻辑操作，并不会创立任何iptables规定，只要当安保组被关联到port时才会真正创立对应的iptables规定。

关联安保组经过Neutron的port-update命令，比如要把虚构机uuid为38147993-08f3-4798-a9ab-380805776a40参与到该安保组:

安保组命令操作参数较多，相对复杂，可以经过Dashboard图形界面操作，如图：

详细操作这里不多引见。

3、安保组成功原理剖析

3.1 虚构机网络流向门路

Linux网络虚构化支持linux bridge以及openvswitch(简称OVS)，OpenStack Neutronml2驱动二者都支持，目前大少数经常使用的是OVS。

不过早期的iptables不支持OVS bridge以及port，因此为了成功安保组，虚构机的tap设施并不是间接衔接到OVSbridge上，而是两边加了一个Linux bridge，经过veth pair衔接Linux bridge以及OVS bridege，这样就可以在Linuxbridge上参与iptables规定成功安保组性能了。

目前大少数的OpenStack环境还遵照如上规定，简化的虚构机流量门路如下：

其中X、Y、Z为虚构机port UUID前11位。

3.2 安保组规定挂在iptables哪条链?

依据前面的基础，不难猜出安保组的iptables规定必需是在filter表成功的，filter表只触及INPUT、FORWARD、OUTPUT三条链，iptables规定流向图可以简化为：

做过主机防火墙的或许第不时觉会以为安保组规定会挂在INPUT以及OUTPUT链上，但依据上方的流程图，假设包不是发给自己的，基本到不了INPUT以及OUTPUT，因此显然在INPUT、OUTPUT基本成功不了安保组规定，因此安保组的iptables规定必需是在FORWARD链上成功的，也就是说计算节点不处置虚构机的包(发给自己的包除外)，只担任转发包。

3.3 安保组规定定义

为了便于前面的测试，我提早创立了一台虚构机int32bit-server-1，IP为192.168.100.10/24，portUUID为3b90700f-1b33-4495-9d64-b41d7dceebd5，并参与到了之前创立的int32bit-test-secgroup-1安保组。

咱们先导出本计算节点的一切tap设施对应Neutron的port，该脚本在githubint32bit/OpenStack_Scripts可以下载:

依据前面的剖析，虚构机安保组是定义在filter表的FORWARD链上的，咱们检查该链的规定:

FORWARD链先跳到neutron-filter-top子链上，neutron-filter-top链会又跳到neutron-openvswi-local，而neutron-openvswi-local链是空链，因此会前往到母链FORWARD上，因此这里第一条规定其实没啥用。

前往到FORWARD链后继续婚配第2条规定，跳转到了neutron-openvswi-FORWARD，咱们检查该链的规定:

该链上一共有4条规定，第1、2台规定对应的tap设施区分为dhcp以及router_interface端口，即准许DHCP以及网关的port经过。

而tap3b90700f-1b显然是虚构机port对应的tap设施(称号为tap+portUUID前11位)，第3、4规定标明无论是从这个tap设施进的还是出的包都进入子链neutron-openvswi-sg-chain处置。

咱们继续检查neutron-openvswi-sg-chain检查链:

从规定咱们可以看出：

显然neutron-openvswi-i3b90700f-1和neutron-openvswi-o3b90700f-1区分对应安保组的入访规定和出访规定，即虚构机的入访规定链为neutron-openvswi-i+ port前缀，虚构机的出访规定链为neutron-openvswi-i + port前缀。

3.4 安保组入访规定

由3.3咱们了解到，安保组入访规定链为neutron-openvswi-i3b90700f-1，咱们检查该链规定:

一共有6条规定：

安保组入访规定中第1、2、3、5、6都是固定的，当有新的安保组战略时就往第4条规定前面追加。

3.5 安保组出访规定

由3.3咱们了解到，安保组入访规定链为neutron-openvswi-o3b90700f-1，咱们检查该链规定:

一共有8条规定:

3.6 安保组经常使用安保组作为婚配条件

前面2.3节提到，安保组不只支持经过IP地址段作为源或许指标的婚配条件，还支持经过指定另一个安保组，这种状况怎样处置呢。

为了测试我把创立了一个新的安保组int32bit-test-secgroup-2以及新的虚构机int32bit-server-2(192.168.100.7)，并且int32bit-server-2关联了安保组int32bit-test-secgroup-2。

同时在int32bit-test-secgroup-1上参与一条入访规定，准许关联int32bit-test-secgroup-2的虚构机访问8080端口:

咱们检查虚构机入访规定链neutron-openvswi-i3b90700f-1:

咱们发现拔出了一条新的规定，编号为4。该规定经常使用了set裁减模块，前面引见过set是用来婚配ipset的，前面的参数NIPv4fc83d82a-5b5d-4c90-80b0-为ipset名，显然是由NIPv4+安保组UUID前缀组成。

咱们检查该ipset：

可见192.168.100.7在ipset汇合中。

因此OpenStack安保组经常使用安保组作为婚配条件时是经过ipset成功的，每个安保组会对应创立一个ipset汇合，关联的虚构机IP会放到这个汇合中，iptables经过ipset婚配成功了安保组婚配性能。

4、安保组anti snoop性能

前面3.5节提到第2条规定，一切的包都会先进入neutron-openvswi-s3b90700f-1子链处置，这个链是干什么的呢?

咱们首先检查下外面的规定:

这条链的处置逻辑很便捷，只放行IP是192.168.100.10并且MAC地址是FA:16:3E:A0:59:BA的包经过。这其实是Neutron自动开启的反诈骗antisnoop性能，只要IP和MAC地址婚配Neutronport调配的能力经过。换句话说，你起了个虚构机IP为192.168.3.1，而后自己手动把网卡的IP窜改为192.168.3.2，必需是不准许经过的。

然而呢，咱们业务又往往有virtualip的需求，最经常出现的如haproxy、pacemaker的vip。OpenStack思考了这种需求，支持用户参与白名单列表，经过port的allowedaddress pairs性能。

比如我有两个虚构机，IP区分为192.168.0.10、192.168.0.11，放开了一个port192.168.0.100作为这个两个虚构机的vip，可以经过Neutron降级port信息成功:

参与后咱们再检查下neutron-openvswi-s3b90700f-1链规定:

可见在最前面参与了一条规定准许IP为192.168.0.100的包经过，此时在虚构机192.168.0.10上把IP改为192.168.0.100也可以ping通了。

5、虚构机访问宿主机怎样办?

咱们曾经知道，安保组是在filter表的FORWARD链上成功的，但假设虚构机的包是去往宿主机时，由于内核判别指标地址就是自己，因此不会流到FORWARD链而是发往INPUT链，那这样岂不就是绕过安保组规定了吗?

处置方法很便捷，只要要把neutron-openvswi-o3b90700f-1再挂到INPUT链就可以了。

咱们检查INPUT链规定:

即:

有人或许会问，那宿主机发往虚构机的包会产生疑问吗?须要在OUTPUT链上参与规定吗?答案是不须要，由于从OUTPUT间接出去，当作反常流程走就可以了。

6、总结

本文首先便捷引见了下iptables，而后引见OpenStack安保组，最后详细剖析了安保组的成功原理。

另外写了一个脚本可以极速导出虚构机的iptables规定，须要在计算节点上运转:

付广平，任职某银行云技术治理中心，担任云计算相关技术钻研。毕业于北京邮电大学，从2013开局从事OpenStack相关上班，介入了OpenStack Nova、Cinder、Oslo等名目社区开发。