Rancher Managed Network實踐

需求提出

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

我們做過一些測試：在與Host網絡的iperf測試比較中，Managed網絡表現出來的性能損耗較嚴重（當然這也與運行Rancher的主機配置有關）。可惜在Rancher當前正式的Release版本中，除Managed網絡外，并未提供其他的Overlay網絡作為可選項。

現實是某些用戶擁有自建數據中心，Rancher被部署到數據中心內部，網絡安全相對已經較有保障。受到業務性質的影響，一些場景對網絡傳輸效率的要求較高。此時Managed網絡就顯得有些無法覆蓋需求了。于是，我們思考能否在不考慮安全性的前提下對Rancher的Managed網絡做一些修改，從而提高網絡傳輸效率。

一個較直接的思路就是去除對業務報文的加密過程。

IPSec基本概念

這一節不準備詳細講解IPSec原理，只將一些重要概念點到為止，有興趣的同學可以下來研究IETF的RFC。

我們首先用一張圖來認識IPSec框架：

IPSec模式

1. 傳輸模式：適用于兩臺主機之間的數據保護。

   
   

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

IPSec安全協議

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

另外，有抓過包的同學會發現，Rancher的IPSec報文與這里基于Tunnel模式+ESP安全協議的封包格式有些不同。實際抓到的報文在外層的IP頭部之后，ESP域之前，還包含了一個使用4500端口的UDP頭部。這是NAT-T功能，它的實現機制是首先判斷是否兩端設備是否都支持NAT-T，然后檢測鏈路上是否存在NAT，一旦兩個條件都滿足就啟動NAT-T，將所有的業務報文使用UDP的4500端口進行傳輸。

保障私密性

IPSec支持使用多種加密算法對傳輸的業務數據進行加密。通過加密把數據從明文變成無法讀懂的密文，從而確保數據的私密性。

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

保障完整性

通過對數據進行HASH運算，產生類似于指紋的數據摘要，連同數據一起傳輸到對端，以確認數據未被非法篡改，保障數據完整性。

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

保障真實性

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

通過身份認證可以保證數據的真實性，確保數據確實是由特定的對端發出的。

常用的身份認證方式包括：Pre-shared key 預共享密鑰、 RSA Signature 數字簽名等。

下圖是隧道模式的ESP封包流程，它反映了如何使用加密算法和驗證算法來生成最終的加密報文。

IKE

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

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

講了這么多理論的東西，現在我們回到Rancher，來看看Rancher的Managed網絡是如何工作的。

Rancher Managed網絡原理

通過進入agent-instance容器查看進程信息可以發現其主要啟動了如下進程：

1. rancher-metadata

2. rancher-dns

3. rancher-net

4. charon 

5. haproxy

6. host-api

rancher-metadata啟動了一個web server，用于響應該agent所轄containers的metadata請求。

rancher-dns實現了一個監聽在IP地址：169.254.169.250上的skydns實例，用于響應該agent所轄container的dns請求。

haproxy其實是一個負載均衡程序，其自帶對member指定端口的healthcheck，此處主要用它來對配置了healthcheck的容器做健康檢查。

host-api在該container內用于將haproxy采集到的數據上報到cattle。

我們重點來分析rancher-net和charon：

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

具體格式如下：

rancher-net通過啟動charon來往xfrm中下發配置，從而維護IPSec的鏈路和policy。

charon用來實現IKE之間的協商并下發rule到xfrm，下一章節實踐中對IPSec加密方式的修改就要通過調用charon的接口來實現。

rancher-net除了通過charon下發xfrm state外，還需要配置xfrm policy，這一塊的實現是在rancher-net中直接執行“ip xfrm policy add”來實現的。

除此之外，還有一個可以查看strongswan狀態的命令行接口swanctl：

在IPSec之外，rancher-net還需要監聽所有的ARP請求，并響應那些目標IP地址通過IPSec tunnel可達，但又不在本Host的ARP請求。

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

監聽8111端口，響應reload和ping的HTT請求。

當有reload請求時，讀取配置文件，將到達配置文件中所有IP的路徑都校驗一遍：

a.如果有新加主機，添加ipsec隧道；

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

c.如果有刪除執行相反操作。

監聽eth0上的ARP請求，響應需要到達IPSec對端IP的ARP請求。

整個IPSec隧道的拓撲如下所示：

Managed網絡實踐

說了這么多，各位都已經蒙圈了吧。話不多少，修改代碼環節隆重上場。

代碼的修改相對簡單，只需要將proposals的第一個加密方式改為null。

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

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

2. 使用sha1的HASH算法； 

3. 使用modp2048的非對稱加密算法進行秘鑰交換。

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

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

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

替換并運行，發現charon協商IKE無法成功，提示“ENCRYPTION_ALGORITHM NULL (key size 20) not supported!”。 這是因為我們將加密算法置為了NULL，系統中的charon不支持。

查詢官網發現NULL需要IKE中openssl的支持，有可能是rancher在編譯charon的時候沒有指定編譯openssl plugin所致：

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

分析代碼發現agent-instance在初始化的時候是通過安裝“rancher/strongswan-package”生成的包來得到charon的。因此，轉到rancher/strongswan-package重新指定./configure --enable-openssl編譯charon。

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

修改之后，環境如下：

兩個Network Agent容器分別為IPSec的端點，另外，每臺host上各運行有一個Iperf容器用于測試。

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

查看xfrm里的ipsec規則，encryption已經為ciper_null，即不加密。

xfrm里的policy列出了到達對端iperf container的策略，即走IPSec tunnel。

跨主機測試

在兩臺主機上的iperf容器，一個作為iperf服務端，另一個作為客戶端做帶寬測試。

在測試過程中，需要抓包確認是否修改已經生效，如下：

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

為了確認這個信息，我們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

這兩臺IP地址正是我們的iperf服務端和客戶端容器的IP地址；因此，可以判斷此時報文是沒有經過加密的；我們的修改已生效。

更改前

更改后

經在兩臺千兆網卡的服務器上5分鐘iperf測試，使用Rancher原生Managed網絡的帶寬為600+Mbps，在修改加密方式為NULL之后，iperf測試帶寬提升為800+Mbps。