雲原生網絡代理 MOSN 透明劫持技術解讀

MOSN 是一款使用 Go 語言開發的網絡代理軟體，作為雲原生的網絡資料平面，旨在為服務提供多協定、子產品化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的簡稱，可以與任何支援 xDS API 的 Service Mesh 內建，亦可以作為獨立的四、七層負載均衡、API Gateway、雲原生 Ingress 等使用。

MOSN：

https://github.com/mosn/mosn

在由 Istio 定義的 Service Mesh 體系中，服務治理相關邏輯由獨立的 Sidecar 程序處理，如服務發現、故障注入、限流熔斷等等。這些處理邏輯是 Service Mesh 着重要解決的問題。通常在談論到 Service Mesh 時，會優先關注在這些點上，但是在落地過程中，有一個問題同等重要但往往容易被忽視。這個問題概括起來，就是流量是如何被導入到 Sidecar 的監聽端口的。

在資料平面的 Sidecar 中攔截進出應用容器的流量，這一直以來就是 Istio Service Mesh 中一切功能的基礎，如何實作透明高效的攔截也是 Service Mesh 設計中的一大難點，本文為大家介紹雲原生網絡代理 MOSN 是如何做到這一點的。

流量接管

如果服務注冊/釋出過程能夠允許适當的修改，這個問題會得到極大的簡化，比如服務釋出方 Sidecar 将位址修改為 127.0.0.1:15001，訂閱方 Sidecar 監聽本機 15001 端口，當訂閱方通路 127.0.0.1:15001 時，流量就自然到達了本端 Sidecar。在這種情況下，無需在網絡層面使用重定向技術就可以達到目的。

服務釋出訂閱修改邏輯框圖

流量轉發流程圖

如上圖中，在釋出服務時，Sidecar 将服務端原本的位址轉換為 Sidecar 自身的端口；服務訂閱時，訂閱方擷取到的端口則是本地 Sidecar 監聽的端口。這一方案的優勢很明顯，邏輯都收斂在了 Sidecar 中，除了需要對 Sidecar 服務注冊/釋出流程進行改造外，不需要其他元件的參與，但是缺點也很明顯，如果業務模型不存在注冊中心，或者是服務釋出/訂閱 SDK 不能進行改造，這個方案就行不通了，而在 Mesh 落地場景中，這個條件恰恰較難滿足。

目前大多數業務的邏輯架構都不符合 Istio 定義的雲原生體系，為了享受到 Service Mesh 在服務治理方面的優勢，需要選擇合适的流量劫持方案。一般而言，流量劫持工作在 L4 層，在進行劫持技術選型時需要考慮三個方面的問題：

• 第一是環境适配，包括容器、虛拟機、實體機、核心、系統發行版等方面的考慮，確定劫持方案在運作環境中能夠正常工作；
• 第二是控制靈活簡單，包括如何維護劫持規則，劫持規則如何下發等；
• 第三是性能，確定在業務運作期間，劫持本身不會帶來過大的開銷；

下面将從這三個層面分析 MOSN 在落地過程中的一些思考。

環境适配

在環境适配性上，最容易想到的是 iptables，作為一項古典網絡技術，iptables 使用簡單，功能靈活，幾乎所有現代生産級核心版本與 OS 發行版都預設具備使用條件，Istio 社群也使用 iptables 做流量透明劫持。

iptables 流量劫持原理圖

盡管環境适應性強，但是基于 iptables 實作透明劫持存在以下問題：

• DNAT 模式下，需要借助于 conntrack 子產品實作連接配接跟蹤，在連接配接數較多的情況下，會造成較大的消耗，同時可能會造成 track 表滿的情況。為了避免這個問題，可以使用 TProxy 取代 DNAT，但受限于核心版本，TProxy 應用于 outbound 存在一定缺陷。
• iptables 屬于常用子產品，全局生效，不能顯式的禁止相關聯的修改，可管控性比較差。
• iptables 重定向流量本質上是通過 loopback 交換資料，outbond 流量将兩次穿越協定棧，在大并發場景下會損失轉發性能。

針對 oubound 流量，還可以使用 hook connect 來實作，如圖所示：

hook connect 邏輯框圖

無論采用哪種透明劫持方案，均需要解決擷取真實目的 IP/端口的問題，使用 iptables 方案通過 getsockopt 方式擷取，TProxy 可以直接讀取目的位址，通過修改調用接口，hook connect 方案讀取方式類似于 TProxy。

由于 MOSN 落地的場景十分複雜，有容器與 VM 甚至實體機環境，有基于 K8s 的雲原生應用，有基于注冊中心的微服務，也存在單體應用，有些場景對性能要求非常高，有些則是夠用即可，針對不同的場景，我們選擇不同的劫持方案進行适配。如果應用程式通過注冊中心釋出/訂閱服務時，可以結合注冊中心劫持流量；在需要用到透明劫持的場景，如果性能壓力不大，使用 iptables DNAT 即可，大并發壓力下使用 TProxy 與 sockmap 改善性能。

配置管理

通常基于申明式體系建構的服務在部署時能夠得到全局資訊，而非申明式體系往往需要在運作期間進行動态的配置修改，由于缺乏全局資訊，在運作期間很難擷取到準确的服務間調用資訊。在生成透明劫持規則時，我們需要明确哪些流量要被重定向到 Sidecar，否則一旦出錯，而 Sidecar 又無法處理這部分流量時，将會使得 Sidecar 變成流量黑洞，比如，某一個容器内的 TCP 流量全部被重定向至 Sidecar，而該容器中存在一個使用私有協定承載應用資料的監控 Agent，而 Sidecar 不能識别該協定導緻無法争取轉發，隻能選擇丢棄。

通常情況下，為了確定 Sidecar 能夠正确的轉發流量，需要滿足兩個條件，首先是要能夠正确識别協定，其次是需要配置轉發規則，明确下一跳。對于不滿足這兩個條件的流量，不應将其重定向至 Sidecar。對于現有的非雲原生應用，同時滿足這兩個條件的代價非常高，比如，某個虛拟機上運作了一個業務，同時還運作了收集 Metrics 的 Agent、日志采集工具、健康檢查工具等等。而基于 L4 規則很難精确的将業務流量重定向至 Sidecar，如果多個業務混部，可能導緻無法在 L4 層進行業務流量的區分。總結起來，為了精确的把流量引至 Sidecar，需要獲得全局的調用關系，這一目标原本應該由 Service Mesh 來完成，而在流量劫持的場景下，卻成為了 Service Mesh 的前提。

為了使用 Service Mesh 而引入大量的部署運維開銷是得不償失的。在落地的過程中，MOSN 引入了多項手段來降低流量劫持的配置難度。我們将需要精确配置重定向規則的工作模式定義為精确比對，與之相對應的是模糊比對，即不要求精确區分出需要劫持的流量。降低配置難度的關鍵在于取消對于精确規則的依賴，在配置模糊規則的前提下，既做到對于關心的業務流量的治理，同時也不影響非業務流量的正常流程。

我們采用 L4 規則與 L7 規則融合的方式下發模糊的比對規則，此規則下除了包含關心的業務流量外，還可能包含預期之外的非業務流量。對于業務流量，Sidecar 根據相應的服務治理規則處理，而對于非業務流量，則保持其預設行為不變。在模糊比對模式下，僅需要為關心的流量配置服務治理與轉發規則，而無需關心 miss match 導緻流量黑洞。在模糊比對之外，MOSN 仍然保留了精确比對能力，可以通過配置項禁用模糊比對，能夠相容之前的工作模式。

MOSN 流量劫持模糊比對邏輯框圖

為了支援更加靈活的配置手段，在配置模糊比對規則時，支援預設白名單與預設黑名單兩種模式。預設黑名單模式适合業務場景簡單，業務流量特征明顯的場景，由于劫持邏輯的輸入流量少，性能損耗小。預設白名單模式适合業務特征明顯不明顯的場景，由于劫持邏輯的輸入流量多，可能存在一定的性能損耗，在這種模式下，可以顯示加入黑名單排除相應的流量，比如通常業務不會使用除了 80 之外的小于 1024 的端口。

MOSN 通過模糊規則比對的手段極大降低了流量劫持的管理成本，在部署 Service Mesh 時，僅需要“大體上正确”即可，無需擔心沒有完全枚舉流量規則而産生流量黑洞，而借助于 Service Mesh，可以得到全局的服務調用資訊，進而能夠對現有服務進行精細化的治理。

資料面性能

iptables 存在一個固有問題是在比對規則數量增多時，比對消耗會随之增加，在規則數量較多的情況下，會對建立連接配接性能造成較大的影響，為了避免這種情況，可使用 ipset 降低比對消耗。此外，在核心版本滿足要求（4.16 以上）的前提下，通過 sockmap 可以縮短封包穿越路徑，進而改善 outbound 方向的轉發性能。

在讨論流量劫持的性能損耗時，需要結合具體的場景來看，比如某些場景中隻有 iptables dnat 能夠滿足環境适配的要求，在這種情況下，需要考慮的是 iptables dnat 的資料面性能是否能夠滿足業務的需求。實際落地過程中，需要結合實際情況與運維難度選擇劫持手段。

總結

本文主要為大家介紹雲原生網絡代理 MOSN 是如何實作透明高效的攔截的。降低劫持規則的管理成本，使得 Service Mesh 的引入不會造成額外的負擔，在落地過程中，可以更加專注在業務邏輯上，能夠充分滿足多語言，多環境下的服務治理需求。

如果大家對 MOSN 有問題以及建議，歡迎與我們交流，也非常歡迎加入 MOSN 開源社群的共建。

MOSN 官網：

https://mosn.io/