Rancher Managed Network的示例分析

166次閱讀

沒有評論

共計 3869 個字符，預計需要花費 10 分鐘才能閱讀完成。

丸趣 TV 小編給大家分享一下 Rancher Managed Network 的示例分析，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

IPSec 基本概念

這一節不準備詳細講解 IPSec 原理，只將一些重要概念點到為止，有興趣的同學可以下來研究 IETF 的 RFC。我們首先用一張圖來認識 IPSec 框架：

IPSec 模式

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

2. 隧道模式：適用于建立 site-2-site 的安全 VPN 隧道。（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

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 image 的方式來替換 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 所致：