背

景

介

紹

OpenStack環境Neutron 的安全組會向虛擬機默認添加?anti-spoof?的規則，將保證虛擬機只能發出／接收以本機Port為原地址或目的地址(IP、MAC)的流量，提高了云的安全性。但是LVS等需要綁定VIP的場景，默認流量是被攔截的。需要做allow pairs設置才能放通流量。

02

業務拓撲

● Director Server分發器

VIP：xx.xx.xx.241

內網IP 主xx.xx.xx.5

? ? ? ? ? ? 備xx.xx.xx.7

Keepalived配置文件路徑 /etc/keepalived/keepalived.conf

● 真實服務器RS關閉ARP，并添加lo:0 IP為VIP

內網(專網)IP xx.xx.xx.8?? xx.xx.xx.10

? ? ? ? ? ? ? ? ? ? ? xx.xx.xx.11 ??xx.xx.xx.13

以上六臺虛擬機都對VIP做過allowed_address_pairs(僅對VIP做的，后面會詳述)。

03

問題現象

配置了LVS的DR模式，配置完成后Client ping VIP可以通，但是發送HTTP請求，沒有反應。抓包發現，Director收到了Client的報文，但是RS沒有收到HTTP請求，只有VRRP報文。

04

排除過程

4.1懷疑是LVS配置問題

Client能ping通VIP，CURL VIP沒響應，LVS 處在SYN_RECV狀態，抓包發現，LB端有進來的VIP報文，RS沒有。問題應該是LB端發不出去，或RS收不到報文。

結果

反復檢查keepalived和RS配置，沒有問題。同樣的配置在非openstack上跑，可以跑通。排除配置問題。

4.2?懷疑是宿主機防火墻問題

4.2.1 懷疑是宿主機本地防火墻規則問題

在查看宿主機防火墻cat /etc/sysconfig/firewalld的時候，發現有一條規則影響業務，注掉并重啟防火墻就可以跑通業務。

重啟宿主機iptables后：

結果

其實并不是這個問題，是重啟防火墻之后，啟用了本地防火墻規則，把原先Neutron的防火墻規則沖掉了，iptables幾乎都空了，所以業務感覺通了。等Neutron同步規則后，還是會不通。

4.2.2懷疑是虛機防火墻問題

一開始出現不通的時候， iptables -F清空虛機里面的iptables規則，發現并沒有實質作用

還是必須重啟宿主機的iptables。

虛機iptables規則：

結果

其實虛機的iptables已經幾乎沒有規則了，也并沒有影響業務的條目。重啟宿主機iptables通，實則還是上一個問題，把宿主機本地Neutron的iptables規則給沖了。

4.2.3懷疑是Neutron安全組問題

后期排查主要是在Neutron安全組方向。必現的場景是，在刪除增加后端或者重啟Neutron-openvswitch-agent的時候，業務就不通了。

● 嘗試分別對LVS節點(xx.xx.xx.5、xx.xx.xx.7)和RS節點(xx.xx.xx.8、xx.xx.xx.10、xx.xx.xx.11、xx.xx.xx.13)做了allow_pairs，但是業務不通。

Dump宿主機防火墻的時候，發現如下規則：

這些條目出現的原因是對Port和VIP做了allow_pairs綁定。會生成對應條目的iptables。由Chain ID追溯，是Neutron-openvswi-FORWARD規則，屬于虛機Port轉發鏈規則，問題應該就是出在這邊。

● 嘗試對LVS的Port加了80端口的放通規則后，業務通了：

結果

確實是安全組導致iptables把流量給drop了，有多個辦法可以規避這個問題：

● 在iptables對應子鏈加規則放行。但是在界面更新或’neutron-openvswitch-agent’重啟的時候，Neutron重新下發規則，會刷掉本地手動加的規則，不可以完全保證業務不通。

● 把端口的port-curity-enable設置成false，但是安全組不再生效

● 寫腳本探測iptables重載，再添加規則。但是規則沒有添加的瞬間，也會出現業務短時間斷的情況。

●? 在’neutron-openvswitch-agent’里添加規則放行，但是需要修改Agent，太麻煩。

●??在安全組設置這個規則，但是沒找到相應的入口。

05

解決方案

5.1 LVS DR模式模型原理

DR模式的工作過程

●??Client 發送Request包到LB服務器的VIP上

●??負載均衡服務器根據VIP選擇對應的RS。然后修改報文目的MAC為RS的MAC地址，將Client的請求發給RS

●??被選擇的RS把應答包直接傳給Client

5.2 問題根本原因

上面的DR模式過程可以看出，LVS轉發過程中不修改IP，只修改DST MAC，Source IP沒變。而由上面的截圖可以看出，allow_pairs在iptables里是用一組IP和MAC的組合規則來放通流量。所以只綁定VIP為allow_pairs，實際是VIP和自己網卡的MAC的規則，而目的MAC在經過LVS的時候已經被修改成后端MAC了，流量自然就過不去。而VRRP報文能出去的原因是IP和MAC都是本機的，在iptables里。

5.3 解決辦法

● 負載均衡器設置

1. 一種辦法，因為Client的CIP是任意的，負載均衡器需要轉發Source IP為CIP的報文，所以可以讓allow_pairs綁定IP為0.0.0.0/0，讓所有的IP可以從Director出去。原理是放開了基于本機MAC的所有IP報文。如：neutron port-update port_id --allowed-address-pairs type=dict list=true ip_address=0.0.0.0/02. 另一種辦法，負載均衡器修改的目的MAC是后端服務器的，可以把后端服務器的MAC都加到allow_pairs。如果MAC不確定的情況，直接設成0:0:0:0:0:0，放開所有的MAC。如：neutron port-update port_id --allowed-address-pairs type=dict list=true ip_address=$VIP mac_address=$RSMAC● 后端設置因為RS需要轉發Source IP為VIP的報文，所以應該對RS對應PORT 做放開VIP的allow_pairs。如：neutron port-update port_id --allowed-address-pairs type=dict list=true ip_address=$VIP

添加后的iptables會出現如下的規則：

問題解決

5.4 可能出現的安全問題

因為上述規則實際上是放開了對應虛機的流量限制，DR模式可以讓任意IP或者MAC能訪問VIP，流量從LVS節點透傳過來，這個對虛機和應用的安全性會有一定的隱患，這里有幾條安全建議：

1.搭建前端硬件防火墻

2.虛機操作日志記錄，權限管理

3.虛機安裝安全軟件

4.虛機arp_announce設置成2(總是使用最合適的網卡來響應)

5.虛機iptables設置，只允許VRRP和對應TCP+PORT的規則

6.更換NAT/TUNNEL/FULLNAT，可以做內外網隔離的模式

06

總結

LVS的特點是需要在Port添加VIP，內部去進行地址的轉換，再發給后端。單純在iptables層去修改問題，還是會被Neutron刷新。可以在安全組里面去修改，也可以在Neutron命令行設置，才能保證設置持久化，不會出現iptables被刷新的問題。

OpenStack的網絡環境iptables規則比較復雜，出現問題的時候，應該在iptables找到自己的IP:Port，NIC Dev ID, 子Chain ID，向上追溯屬于哪條鏈、哪個表，再結合網絡拓撲和業務場景去規劃和設置確定問題在哪。

單純考慮到VIP是不夠的。類似問題解決辦法不是一成不變的，除了剛才提到的，還有多種辦法，可以關閉Port安全組，也可以在安全組添加條目，或者修改agent代碼關閉Port的firewall或者添加accept條目等等，方法有很多，需要權衡利弊根據需求選擇。

End

往期推薦

【干貨分享】|??深度解析python之生成器

【干貨分享】|??大云彈性計算產品BC-EC全面支持跨版本升級

【干貨分享】|??為啥熱遷移總是斷網呢？