Istio 流量劫持過程

好運來了發表於2020-05-29

開篇

Istio 流量劫持的文章其實目前可以在servicemesher社群找到一篇非常詳細的文章，可查閱：Istio 中的 Sidecar 注入及透明流量劫持過程詳解。特別是博主整理的那張“流量劫持示意圖”，已經可以很清晰的看出來劫持流程。這裡我藉著那張圖片解釋一版該圖片的文字版本。在開始文字版前如果對iptables命令如果不是非常瞭解的話建議先重點看下下面的兩篇文章，深入淺出的解釋了該命令的概念及用法：

  1. iptables概念 - 以通俗易懂的方式描述iptables的相關概念
  2. iptables指南 - iptables命令用法指南

這裡引用iptables的一張報文流向圖（版權歸原博主所有）

iptables-routing

當客戶端訪問伺服器的web服務時，客戶端傳送報文到網路卡，而tcp/ip協議棧是屬於核心的一部分，所以，客戶端的資訊會通過核心的TCP協議傳輸到使用者空間中的web服務中，而此時，客戶端報文的目標終點為web服務所監聽的套接字（IP：Port）上，當web服務需要響應客戶端請求時，web服務發出的響應報文的目標終點則為客戶端，這個時候，web服務所監聽的IP與埠反而變成了原點。 -- 引用自 zsythink

上面這部分描述相當重要，它是理解sidecar在進行流量劫持的基礎之一。

下面我們分析下昨天istio-init啟動時執行的istio-iptables命令

nsenter -t 8533 -n iptables -t nat -S

# 預設
# 為PREROUTING/INPUT/OUTPUT/POSTROUTING鏈設定策略為接收資料包(ACCEPT)
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT

# 自定義4個istio的規則鏈
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT

# 進入PREROUTING鏈tcp協議請求全部定向至 ISTIO_INBOUND 自定義鏈進行規則匹配
-A PREROUTING -p tcp -j ISTIO_INBOUND
# 進入OUTPUT鏈tcp協議請求全部定向至 ISTIO_OUTPUT 自定義鏈進行規則匹配
-A OUTPUT -p tcp -j ISTIO_OUTPUT

# 入口
# tcp協議請求且請求埠為22/15090/15021/15020的請求停止執行當前鏈中的後續Rules，並執行下一個鏈
-A ISTIO_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
# tcp協議且埠不是22/15090/15021/15020的請求全部定向至 ISTIO_IN_REDIRECT
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
# 將重定向於此的tcp協議請求流量全部重定向至15006埠(envoy入口流量埠)
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006

# 出口
#  源IP地址為localhost且資料包出口為 ”lo“ 的流量都返回到它的呼叫點中的下一條鏈執行(1)
-A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
#  目的地非localhost，資料包出口為 ”lo“，是istio-proxy使用者的流量轉發至 ISTIO_REDIRECT (2)
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
#  資料包出口為 ”lo“，非istio-proxy使用者的流量都返回到它的呼叫點中的下一條鏈執行(1)
-A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
#  istio-proxy 使用者的流量都返回到它的呼叫點中的下一條鏈執行
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
#  目的地非localhost，資料包出口為 ”lo“，是istio-proxy使用者組的流量轉發至 ISTIO_REDIRECT(2)
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
#  資料包出口為 ”lo“ 且非istio-proxy使用者組流量都返回到它的呼叫點中的下一條鏈執行(1)
-A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
#  到 istio-proxy 使用者組的流量都返回到它的呼叫點中的下一條鏈執行(1)
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
#  所有目的地為localhost的流量都返回到它的呼叫點中的下一條鏈執行(1)
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
#  其他不滿足上述rules的流量全部轉發到 ISTIO_REDIRECT  (2)
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
#  將重定向於此的tcp協議請求流量全部重定向至15001埠(envoy出口流量埠)
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

-m = --match. istio-proxy 使用者身份執行， uid-owner 1337 為使用者ID / gid-owner 1337 為使用者組，即 sidecar 所處的使用者空間，這也是 istio- proxy 容器預設使用的使用者。

注意文中打括號的地方

(1) 代表流量會直接執行下一個攔截鏈，本文中下一個攔截鏈為POSTROUTING鏈

(2) 代表流量會被重定向至envoy出口流量埠

根據上面的規則小結一下：

ISTIO_INBOUND 鏈：所有進入Pod但非指定埠(如22)的流量全部重定向至15006埠(envoy入口流量埠)進行攔截處理。

ISTIO_OUTPUT 鏈：所有流出Pod由 istio-proxy 使用者空間發出且目的地不為localhost的流量全部重定向至15001埠（envoy出口流量埠），其他流量全部直接放行至下一個POSTROUTING鏈，不用被envoy攔截處理。

其實仔細思考下可以看到，流量攔截主要發生在兩個地方：

  1. 使用者請求到達Pod時對應流量會被攔截至sidecar進行處理，由sidecar請求業務服務
  2. 當業務服務響應使用者請求時該響應再次被攔截至sidecar，由sidecar響應使用者

再看下iptables nat 表的規則

nsenter -t 8533 -n iptables -t nat -L -v


Chain PREROUTING (policy ACCEPT 3435 packets, 206K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3435  206K ISTIO_INBOUND  tcp  --  any    any     anywhere             anywhere      (1)       

Chain INPUT (policy ACCEPT 3435 packets, 206K bytes)                                  (5)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 599 packets, 54757 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   22  1320 ISTIO_OUTPUT  tcp  --  any    any     anywhere             anywhere            

Chain POSTROUTING (policy ACCEPT 599 packets, 54757 bytes)                            (8)
 pkts bytes target     prot opt in     out     source               destination         

Chain ISTIO_INBOUND (1 references)                                                    (2) 
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     tcp  --  any    any     anywhere             anywhere             tcp dpt:22
    1    60 RETURN     tcp  --  any    any     anywhere             anywhere             tcp dpt:15090
 3434  206K RETURN     tcp  --  any    any     anywhere             anywhere             tcp dpt:15021
    0     0 RETURN     tcp  --  any    any     anywhere             anywhere             tcp dpt:15020
    0     0 ISTIO_IN_REDIRECT  tcp  --  any    any     anywhere             anywhere  (3)        

Chain ISTIO_IN_REDIRECT (3 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 15006                                                                     (4)

Chain ISTIO_OUTPUT (1 references)                                                     (6)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  any    lo      127.0.0.6            anywhere            
    0     0 ISTIO_IN_REDIRECT  all  --  any    lo      anywhere            !localhost            owner UID match 1337
    0     0 RETURN     all  --  any    lo      anywhere             anywhere             ! owner UID match 1337
   22  1320 RETURN     all  --  any    any     anywhere             anywhere             owner UID match 1337
    0     0 ISTIO_IN_REDIRECT  all  --  any    lo      anywhere            !localhost            owner GID match 1337
    0     0 RETURN     all  --  any    lo      anywhere             anywhere             ! owner GID match 1337
    0     0 RETURN     all  --  any    any     anywhere             anywhere             owner GID match 1337
    0     0 RETURN     all  --  any    any     anywhere             localhost           
    0     0 ISTIO_REDIRECT  all  --  any    any     anywhere             anywhere            

Chain ISTIO_REDIRECT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 15001

讓我們一起再來仔細看下面這個圖片，同步觀察上面iptables chain的規則。這裡的分析主要針對紅色的數字一對一解釋：

envoy-sidecar-traffic-interception

  1. productpage 服務對reviews 服務傳送 TCP 連線請求
  2. 請求進入reviews服務所在Pod核心空間，被netfilter攔截入口流量，經過PREROUTING鏈然後轉發至ISTIO_INBOUND鏈
  3. 在被ISTIO_INBOUND鏈被這個規則-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT攔截再次轉發至ISTIO_IN_REDIRECT鏈
  4. ISTIO_IN_REDIRECT鏈直接重定向至 envoy監聽的 15006 入口流量埠
  5. 在 envoy 內部經過一系列入口流量治理動作後，發出TCP連線請求 reviews 服務，這一步對envoy來說屬於出口流量，會被netfilter攔截轉發至出口流量OUTPUT鏈
  6. OUTPUT鏈轉發流量至ISTIO_OUTPUT鏈
  7. 目的地為localhost，不能匹配到轉發規則鏈，直接RETURN到下一個鏈，即POSTROUTING鏈
  8. sidecar發出的請求到達reviews服務9080埠
  9. reviews服務處理完業務邏輯後響應sidecar，這一步對reviews服務來說屬於出口流量，再次被netfilter攔截轉發至出口流量OUTPUT鏈
  10. OUTPUT鏈轉發流量至ISTIO_OUTPUT鏈
  11. 傳送非localhost請求且為istio-proxy使用者空間的流量被轉發至 ISTIO_REDIRECT鏈
  12. ISTIO_REDIRECT鏈直接重定向至 envoy監聽的 15001 出口流量埠
  13. 在 envoy 內部經過一系列出口流量治理動作後繼續傳送響應資料，響應時又會被netfilter攔截轉發至出口流量OUTPUT鏈
  14. OUTPUT鏈轉發流量至ISTIO_OUTPUT鏈
  15. 流量直接RETURN到下一個鏈，即POSTROUTING鏈

針對上文其實我還有兩個疑問點，還請大家不吝指教：

  • 上面的理解沒有寫第16點，博主的圖中的16點還會再進 ISTIO_REDIRECT鏈，我們可以看到 ISTIO_REDIRECT鏈中只有一個改寫埠轉發的規則，這樣豈不是會進入一個死迴圈？或者是我還沒有理解清楚
  • envoy 轉發流量是不是自己新建立的tcp 連線請求還是通過修改請求報文地址來實現的。因為對c++瞭解有限，無法查閱其原始碼去一探究竟

從整個流量攔截流程大家也可以看出，路徑這麼長， 在大併發場景下肯定會損失轉發效能。目前業界有一些框架在試著縮短這個攔截路徑，讓大家拭目以待吧。

參考文獻

https://www.servicemesher.com/blog/sidecar-injection-iptables-and-traffic-routing/

https://www.frozentux.net/iptables-tutorial/cn/iptables-tutorial-cn-1.1.19.html#REDIRECTTARGET

http://www.zsythink.net/archives/1199

相關文章