過去一直以為，neutron的安全組是由iptables實現，網上不少文章也印證這個想法，他們的依據如下圖：

ovs的Port不具備安全功能，因此接入一個qbr-xxx的bridge，這個bridge的實現載體是Linux Bridge，借助iptables實現防火墻功能——原本我也是這么認為的。
直到有一次，在查找具體的安全組iptables規則時，并沒有發現相關的rules，對此產生了懷疑。
查看ml2_conf.ini的配置文件后，發現我們環境中的firewall driver是openvswitch，那不用說肯定是通過流表實現安全組了。

firewall_driver屬性在ml2/plugins/ml2_conf.ini配置文件中：

以流表形式存在的安全組，對比iptables的實現，是更具備性能優勢的。iptables規則的存在，意味著數據包需要走一遍內核協議棧，對性能的損耗十分明顯。
在我們的生產環境中，每增加一條iptables規則，就會損失2w的PPS，iptables規則的數量是需要得到控制的。

查看neutron（R版）安全組相關的代碼：

neutron的通信機制是以neutron-server接受restful API請求，操作DB，并轉發給各類agent工作的流程。圖中代碼位于ovs-agent部分，文件路徑是neutron/agent/securitygroups_rpc.py。
neutron-server收到的安全組更新請求，在操作完數據庫后，通過rabbitmq發送給ovs-agent，異步調用此函數，通過驅動實現抽象方法，調用到具體的驅動中去干活。
可以看到，neutron支持iptables和ovs兩種安全組驅動，用戶通過firewall_driver可以選擇。第一條是抽象類方法，第二條是驅動實現的模板，后面的IptablesFirewallDriver和OVSFirewallDriver才是實現的驅動。

二者都是通過刷新緩存，去調用命令行添加流表或iptables rules。
通過一條命令，為環境中的某個port添加一條安全組：

openstack port set 90ee4f00-3fe9-4e71-85da-e8ce19901091 --security-group fe66a3c9-723c-4faf-bbbd-d7cffe78d663

在ovs-agent的日志中抓到如下內容：

梳理一下日志內容，意思是添加這樣一條安全組規則：

'direction': 'ingress', 'protocol': 6, 'ethertype': 'IPv4', 'port_range_max': 65535, 'source_ip_prefix': '0.0.0.0/0', 'port_range_min': 1

會為添加如下的流表：

• dl_type網絡類型：2048即十六進制0x800，指代IPv4協議
• reg_port記錄端口：目標端口在openflow中的編號，指的是添加安全組的端口
• nw_proto協議：6代表tcp
• tcp_dst：端口按位匹配，這個端口是匹配的端口，即安全組規則中指定的1-65535
  （openflow流表在表示端口范圍時，有兩種選擇，例如1-65535，要么它添加65535條流表；要么通過port/mask的方式，1到65535按二進制展開，以掩碼記錄一個范圍，與CIDR相似，如上案例中所有tcp_dst組合起來剛好是1-65535）
• table 82：流表添加到82表
• resubmit(,83)：轉發到83表
• priority 77：優先級77

所有能匹配到流表規則的，都會被轉發到83表，即代表著已經通過安全組了，83表可以轉發給連接安全組的tap口。

總結

以上是生活随笔為你收集整理的OpenStack Neutron安全组机制探索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。