Rancher Managed Network實(shí)踐

需求提出

我們知道，Rancher原生的Managed網(wǎng)絡(luò)是通過IPsec來(lái)建立起安全隧道來(lái)保障各service之間可達(dá)性的。相比于其他一些×××技術(shù)，IPSec最大的優(yōu)勢(shì)在于其安全性；這種安全除了指業(yè)務(wù)數(shù)據(jù)加密傳輸外，還包括了一套秘鑰交換的安全機(jī)制，這是諸如VXLAN之類的其他L3 ×××技術(shù)無(wú)法匹敵的。但正是為了提供這一層安全機(jī)制，IPSec需要在數(shù)據(jù)交換過程中對(duì)報(bào)文做逐一加密，勢(shì)必消耗CPU資源，影響傳輸效率。

我們做過一些測(cè)試：在與Host網(wǎng)絡(luò)的iperf測(cè)試比較中，Managed網(wǎng)絡(luò)表現(xiàn)出來(lái)的性能損耗較嚴(yán)重（當(dāng)然這也與運(yùn)行Rancher的主機(jī)配置有關(guān)）?？上г赗ancher當(dāng)前正式的Release版本中，除Managed網(wǎng)絡(luò)外，并未提供其他的Overlay網(wǎng)絡(luò)作為可選項(xiàng)。

現(xiàn)實(shí)是某些用戶擁有自建數(shù)據(jù)中心，Rancher被部署到數(shù)據(jù)中心內(nèi)部，網(wǎng)絡(luò)安全相對(duì)已經(jīng)較有保障。受到業(yè)務(wù)性質(zhì)的影響，一些場(chǎng)景對(duì)網(wǎng)絡(luò)傳輸效率的要求較高。此時(shí)Managed網(wǎng)絡(luò)就顯得有些無(wú)法覆蓋需求了。于是，我們思考能否在不考慮安全性的前提下對(duì)Rancher的Managed網(wǎng)絡(luò)做一些修改，從而提高網(wǎng)絡(luò)傳輸效率。

一個(gè)較直接的思路就是去除對(duì)業(yè)務(wù)報(bào)文的加密過程。

IPSec基本概念

這一節(jié)不準(zhǔn)備詳細(xì)講解IPSec原理，只將一些重要概念點(diǎn)到為止，有興趣的同學(xué)可以下來(lái)研究IETF的RFC。

我們首先用一張圖來(lái)認(rèn)識(shí)IPSec框架：

IPSec模式

1. 傳輸模式：適用于兩臺(tái)主機(jī)之間的數(shù)據(jù)保護(hù)。

   
   

2. 隧道模式：適用于建立site-2-site的安全×××隧道。（Rancher Managed網(wǎng)絡(luò)顯然是要為Host上的所有Containers打通一條加密隧道，是使用隧道模式）

IPSec安全協(xié)議

安全協(xié)議包括AH、ESP以及它們的組合AH-ESP，Rancher中使用的是ESP，通過下圖我們可以形象的了解IPSec的模式和安全協(xié)議之間的關(guān)系：

另外，有抓過包的同學(xué)會(huì)發(fā)現(xiàn)，Rancher的IPSec報(bào)文與這里基于Tunnel模式+ESP安全協(xié)議的封包格式有些不同。實(shí)際抓到的報(bào)文在外層的IP頭部之后，ESP域之前，還包含了一個(gè)使用4500端口的UDP頭部。這是NAT-T功能，它的實(shí)現(xiàn)機(jī)制是首先判斷是否兩端設(shè)備是否都支持NAT-T，然后檢測(cè)鏈路上是否存在NAT，一旦兩個(gè)條件都滿足就啟動(dòng)NAT-T，將所有的業(yè)務(wù)報(bào)文使用UDP的4500端口進(jìn)行傳輸。

保障私密性

IPSec支持使用多種加密算法對(duì)傳輸?shù)臉I(yè)務(wù)數(shù)據(jù)進(jìn)行加密。通過加密把數(shù)據(jù)從明文變成無(wú)法讀懂的密文，從而確保數(shù)據(jù)的私密性。

加密算法分為：對(duì)稱加密算法（DES/AES/3DES等）與非對(duì)稱加密算法（比如RSA）

保障完整性

通過對(duì)數(shù)據(jù)進(jìn)行HASH運(yùn)算，產(chǎn)生類似于指紋的數(shù)據(jù)摘要，連同數(shù)據(jù)一起傳輸?shù)綄?duì)端，以確認(rèn)數(shù)據(jù)未被非法篡改，保障數(shù)據(jù)完整性。

常見的HASH算法有MD5/SHA等。

保障真實(shí)性

對(duì)稱加密和HASH都要求通信雙方具有相同的密鑰，在雙方之間安全地傳遞密鑰就需要一套密鑰交換算法。

通過身份認(rèn)證可以保證數(shù)據(jù)的真實(shí)性，確保數(shù)據(jù)確實(shí)是由特定的對(duì)端發(fā)出的。

常用的身份認(rèn)證方式包括：Pre-shared key 預(yù)共享密鑰、 RSA Signature 數(shù)字簽名等。

下圖是隧道模式的ESP封包流程，它反映了如何使用加密算法和驗(yàn)證算法來(lái)生成最終的加密報(bào)文。

IKE

另外，IPSec還包括IKE。IKE是一種安全機(jī)制，提供端與端之間的動(dòng)態(tài)認(rèn)證，為IPsec提供了自動(dòng)協(xié)商交換密鑰、建立SA的服務(wù)，簡(jiǎn)化IPsec的使用、管理（配置和維護(hù)）工作。IKE不是在網(wǎng)絡(luò)上直接傳輸密鑰，而是通過一系列數(shù)據(jù)的交換，最終計(jì)算出雙方共享的密鑰。有了IKE，IPsec很多參數(shù)（如：密鑰）都可以自動(dòng)建立，降低了手工配置的復(fù)雜度。

IKE使用UDP端口500，通過使用特定的密鑰交換算法進(jìn)行秘鑰交換。常見的算法有DH和RSA算法。

講了這么多理論的東西，現(xiàn)在我們回到Rancher，來(lái)看看Rancher的Managed網(wǎng)絡(luò)是如何工作的。

Rancher Managed網(wǎng)絡(luò)原理

通過進(jìn)入agent-instance容器查看進(jìn)程信息可以發(fā)現(xiàn)其主要啟動(dòng)了如下進(jìn)程：

1. rancher-metadata

2. rancher-dns

3. rancher-net

4. charon 

5. haproxy

6. host-api

rancher-metadata啟動(dòng)了一個(gè)web server，用于響應(yīng)該agent所轄containers的metadata請(qǐng)求。

rancher-dns實(shí)現(xiàn)了一個(gè)監(jiān)聽在IP地址：169.254.169.250上的skydns實(shí)例，用于響應(yīng)該agent所轄container的dns請(qǐng)求。

haproxy其實(shí)是一個(gè)負(fù)載均衡程序，其自帶對(duì)member指定端口的healthcheck，此處主要用它來(lái)對(duì)配置了healthcheck的容器做健康檢查。

host-api在該container內(nèi)用于將haproxy采集到的數(shù)據(jù)上報(bào)到cattle。

我們重點(diǎn)來(lái)分析rancher-net和charon：

rancher-net的配置主要基于文件："/var/lib/cattle/etc/cattle/ipsec/config.json" ， 該文件包含了Environment內(nèi)部所有Managed Network的Container地址信息。

具體格式如下：

rancher-net通過啟動(dòng)charon來(lái)往xfrm中下發(fā)配置，從而維護(hù)IPSec的鏈路和policy。

charon用來(lái)實(shí)現(xiàn)IKE之間的協(xié)商并下發(fā)rule到xfrm，下一章節(jié)實(shí)踐中對(duì)IPSec加密方式的修改就要通過調(diào)用charon的接口來(lái)實(shí)現(xiàn)。

rancher-net除了通過charon下發(fā)xfrm state外，還需要配置xfrm policy，這一塊的實(shí)現(xiàn)是在rancher-net中直接執(zhí)行“ip xfrm policy add”來(lái)實(shí)現(xiàn)的。

除此之外，還有一個(gè)可以查看strongswan狀態(tài)的命令行接口swanctl：

在IPSec之外，rancher-net還需要監(jiān)聽所有的ARP請(qǐng)求，并響應(yīng)那些目標(biāo)IP地址通過IPSec tunnel可達(dá)，但又不在本Host的ARP請(qǐng)求。

綜上，rancher-net的功能包含：

監(jiān)聽8111端口，響應(yīng)reload和ping的HTT請(qǐng)求。

當(dāng)有reload請(qǐng)求時(shí)，讀取配置文件，將到達(dá)配置文件中所有IP的路徑都校驗(yàn)一遍：

a.如果有新加主機(jī)，添加ipsec隧道；

b.如果有新加container，但是已經(jīng)存在IPSec，更新xfrm policy；

c.如果有刪除執(zhí)行相反操作。

監(jiān)聽eth0上的ARP請(qǐng)求，響應(yīng)需要到達(dá)IPSec對(duì)端IP的ARP請(qǐng)求。

整個(gè)IPSec隧道的拓?fù)淙缦滤荆?/p>

Managed網(wǎng)絡(luò)實(shí)踐

說了這么多，各位都已經(jīng)蒙圈了吧。話不多少，修改代碼環(huán)節(jié)隆重上場(chǎng)。

代碼的修改相對(duì)簡(jiǎn)單，只需要將proposals的第一個(gè)加密方式改為null。

如：“null-sha1-modp2048” 代表：

1. 使用對(duì)稱加密方式為null（不加密）；                   

2. 使用sha1的HASH算法； 

3. 使用modp2048的非對(duì)稱加密算法進(jìn)行秘鑰交換。

然后使用Dockerfile.dapper重新編譯代碼，確保沒有編譯錯(cuò)誤。

我們知道，所有agent上的包均是啟動(dòng)時(shí)從cattle拉下來(lái)的；因此，通過更新docker p_w_picpath的方式來(lái)替換rancher-net是沒有用的。

為了做測(cè)試，我們先直接將編譯出來(lái)的rancher-net可執(zhí)行文件通過docker cp替換掉agent-instance中的rancher-net。

替換并運(yùn)行，發(fā)現(xiàn)charon協(xié)商IKE無(wú)法成功，提示“ENCRYPTION_ALGORITHM NULL (key size 20) not supported!”。 這是因?yàn)槲覀儗⒓用芩惴ㄖ脼榱薔ULL，系統(tǒng)中的charon不支持。

查詢官網(wǎng)發(fā)現(xiàn)NULL需要IKE中openssl的支持，有可能是rancher在編譯charon的時(shí)候沒有指定編譯openssl plugin所致：

修改方法是charon編譯的時(shí)候指定參數(shù)--enable-openssl 見：  [https://lists.strongswan.org/pipermail/dev/2011-February/000253.html]

分析代碼發(fā)現(xiàn)agent-instance在初始化的時(shí)候是通過安裝“rancher/strongswan-package”生成的包來(lái)得到charon的。因此，轉(zhuǎn)到rancher/strongswan-package重新指定./configure --enable-openssl編譯charon。

生成新的可執(zhí)行文件后，先執(zhí)行“ip xfrm state flush” 和 “ip xfrm policy flush”， 然后再重啟rancher-net和charon；如果先不刷掉policy和state會(huì)導(dǎo)致新添加的ipsec無(wú)法生效。

修改之后，環(huán)境如下：

兩個(gè)Network Agent容器分別為IPSec的端點(diǎn)，另外，每臺(tái)host上各運(yùn)行有一個(gè)Iperf容器用于測(cè)試。

通過swanctl --list-algs可以看到，所有支持的加密算法，其中由于我們load了openssl，已經(jīng)能夠支持NULL了。

查看xfrm里的ipsec規(guī)則，encryption已經(jīng)為ciper_null，即不加密。

xfrm里的policy列出了到達(dá)對(duì)端iperf container的策略，即走IPSec tunnel。

跨主機(jī)測(cè)試

在兩臺(tái)主機(jī)上的iperf容器，一個(gè)作為iperf服務(wù)端，另一個(gè)作為客戶端做帶寬測(cè)試。

在測(cè)試過程中，需要抓包確認(rèn)是否修改已經(jīng)生效，如下：

可以看到，ESP sequence之后是0X45 0X00的，顯然這是一個(gè)RAW的IP header。

為了確認(rèn)這個(gè)信息，我們decode出該IP header中的src IP和dst IP，分別為：

0x0A 0X2A 0XF4 0XFA 和0x0A 0x2A 0xB4 0xF9

0x0A 0X2A 0XF4 0XFA = 10.42.224.250

0x0A 0x2A 0xB4 0xF9 = 10.42.180.249

這兩臺(tái)IP地址正是我們的iperf服務(wù)端和客戶端容器的IP地址；因此，可以判斷此時(shí)報(bào)文是沒有經(jīng)過加密的；我們的修改已生效。

更改前

更改后

經(jīng)在兩臺(tái)千兆網(wǎng)卡的服務(wù)器上5分鐘iperf測(cè)試，使用Rancher原生Managed網(wǎng)絡(luò)的帶寬為600+Mbps，在修改加密方式為NULL之后，iperf測(cè)試帶寬提升為800+Mbps。