大家好，我是二哥。

上一篇文章本意是給大家一個新的視角來研究 istio route 的細節。不過后臺不少同學私信我說，一直沒有辦法理解 iptables ，也就不想細看那篇文章了。二哥一看就慌了，為了讓大家能安心地研究那篇文章，我就先來聊聊 iptables ，準確地說我們需要聊的是 netfilter 。

理解 iptables 其實不難，難的是看懂 iptables 是如何配合協議棧處理流量的。本篇除了聊 iptables 之外，更重要的是二哥會帶大家一探協議棧和 iptables 密切配合過程。最后我以 istio route 為例來看看它是如何利用 iptables 將網絡包透明地劫持到了 Envoy 的 Outbound hanlder 15001 端口。

本文會混用流量、數據包、網絡包這些名詞，準確地說，它們指代的是內核數據結構 skb (sk_buffer)。

這是一篇長文，誠意滿滿，干貨滿滿，掉發也滿滿。如果你已經對 iptables/netfilter 很熟悉了，那可以跳過前兩部分。

在開始之前，我們先區分兩個概念：

• netfilter：內核中對數據包進行控制、修改和過濾（manipulation and filtering）的框架 。一個著名的實現是內核模塊 ip_tables 。
• iptables：客戶端命令行，用于操作（CRUD）各種規則來干預內核協議棧的行為。

大家日常工作中，碰到直接上手操作 netfilter 的機會越來越少了。但這不表示 netfilter 不重要。實際上 netfilter 是 K8s 網絡的基礎，即使在kubernetes v1.8 中引入了 ipvs 模式，ipvs 的著力點也是 netfilter 。不信你看下面的一段規則。ipvs 介入工作的前提是它得作為規則的一部分，讓 netfilter 框架在合適的時機點運行。

iptables -t nat -A POSTROUTING -m ipvs --vaddr 10.10.0.1 --vport 8410 -j MASQUERADE

肯定有另一部分同學有疑惑：既然平時都不怎么用它了，為什么還要學習 netfilter 呢？

不知道大家有沒有另外一個疑惑：既然整個小學都不可能用到微積分，為什么小學的數學教師需要學高等數學呢？這其實涉及到處理問題時的一個角度問題：如果解決一個問題只需要 3 分功力，你最好得具有 6 成內功。只有這樣你才能俯視而不是仰視或者平視它，唯有俯視方得從容。

1、只看 iptables

文首提到 iptables 是客戶端命令，用于操作各種規則來干預內核協議棧的行為。那它具體是如何使用的呢？

先來看命令長什么樣子的：

iptables [-t <table-name>] <command> <chain-name> <parameter-1> <option-1> <parameter-n> <option-n>

再來看一個使用示例：

iptables -t filter -I INPUT -s 1.2.3.4 -p tcp --dport 22 -j ACCEPT  iptables -t filter -I INPUT -p tcp --dport 22 -j DROP

（1）四表五鏈

圖 1：四表五鏈（橫鏈豎表，橫為鏈，豎為表） 圖片來源：公眾號“開發內功修煉”

圖中橫向的四個框表示四表，對應于 iptables 命令里面的 -t <table-name> 。如果不指定，那么默認的 table 是 filter 。其實還有一個 security 表，用于在數據包上應用 SELinux ，這張表并不常用，故本篇我們略過。

圖中第 1 列表示的五個框叫做五鏈，對應于命令里面的 <chain-name> 。每個鏈像竹簽一樣串著不少肉串。這些肉串叫規則，它們的種類不同，且由不同的表提供。比如 mangle 表可能提供的是羊肉串，而 nat 表提供的是牛肉串，filter 表提供的是雞肉串。

這四個表的具體作用我就不細講了，大家可以到網上搜索出更詳細的答案。但下面這兩點是重點（重點，重點，重點），你一定要記得。

• 這五個預置的鏈直接源自于 Netfilter 的鉤子，它們與四張規則表的關系是固定的。用戶即不能增加自定義表也不能修改圖 1 中已有的表與鏈的關系，但可以增加自定義的鏈（見下文）。
  新增的自定義鏈與 Netfilter 的鉤子沒有天然的對應關系。自定義鏈不會被自動觸發，只有顯式地使用 JUMP 行為（見后文），才能從默認的五條鏈中跳轉過去執行它們。
• 每個命名空間都是有自己獨立的 iptables 規則，這當然也包括四表五鏈。

表、鏈和規則之間的關系，一句話總結就是：規則是執行的最小單元，鏈決定了規則被執行的時機，而表則限定了規則的類別。鏈的執行時機詳見后文。

（2） command

命令中的 command 是啥？它是一些由大寫字母表示的動作。見圖 2 所示。比如 -A 用于將一個新規則插入到鏈上，嗯，就是把肉串插到竹簽上。每一次用 -A 這樣的 command 調用 iptables ，都會在對應的鏈和表所形成的宮格里面插入一個新的規則。

圖 2：iptables command 列表

（3）自定義鏈

我們可以用 -N 來創建一個新鏈。如果不用 -t 來指定 table 的話，新建的 chain 默認使用 filter table 。熟悉自定義 chain 的創建過程非常重要，因為后文我們要分析的 istio route 就自建了不少鏈。

二哥再強調一遍：自定義鏈不能被 netfilter 自動執行，只有從五大入口鏈那里通過 -j target 才能跳轉到自定義鏈（例見后文）。

下面的例子里，自定義了一個 chain LANCE-OUTPUT ，可以看到它被放到了 table filter 里面。

# 自定義 chain LANCE-OUTPUT[root@xx usr]# iptables -N LANCE-OUTPUT
[root@xx usr]# iptables -L -t filterChain INPUT (policy ACCEPT)target     prot opt source               destination        
Chain FORWARD (policy ACCEPT)target     prot opt source               destination        
Chain OUTPUT (policy ACCEPT)target     prot opt source               destination        
Chain LANCE-OUTPUT (0 references)target     prot opt source               destination

然后用 -A 來追加一個規則到這個自定義鏈里面。

# 追加一個規則到自定義鏈 LANCE-OUTPUT[root@xx usr]# iptables -A LANCE-OUTPUT -m comment --comment "kubernetes service portals"
[root@xx usr]# iptables -L -t filterChain INPUT (policy ACCEPT)target     prot opt source               destination        
Chain FORWARD (policy ACCEPT)target     prot opt source               destination        
Chain OUTPUT (policy ACCEPT)target     prot opt source               destination
Chain LANCE-OUTPUT (0 references)target     prot opt source               destination        all  --  anywhere             anywhere             /* kubernetes service portals */

（4）parameter / option

光有 command 還不行，它太粗獷了，得細膩、得精準控制。這就需要通過 parameter 來實現。<parameter-1> <option-1> 里面填什么呢？看你喜歡，你有若干個選擇，比如文首示例里面的 -s 1.2.3.4 和 -p tcp --dport 22 。有一些 parameter 還提供了額外的以 -- 開頭的 額外 match option ，比如對 -p tcp ，你可以添加  --dport 22 這樣的額外 match option ，用以更精準地控制要命中的規則。除了 tcp 外你還有  -p udp   -p icmp 可供選擇。

下面是可供使用的 parameter 列表。

圖 3：iptables parameter 列表

（5）額外的 match option

這就結束了嗎？不，還有大招沒有放。我們來看下面這個例子。例子很平淡，重點看 -m 。-m comment 表示這個規則需要加載 comment 模塊，從字面意思你大概能猜得出來它可以干啥。對，就是給這條規則加點注釋。通過 --comment xxx  這個 option ，你可以添加最多 265 個字符的注釋，前文在介紹用 -A 命令追加規則到自定義鏈時，從 iptables -L -t filter 的輸出里面你可以體驗到這些注釋的作用。

iptables -A INPUT -i eth1 -m comment --comment "my local LAN"

通過 -m 我們可以調用包括 set / ipvs 在內的各種擴展模塊。有多少模塊可以選擇呢？多到沒朋友，不信你到這個鏈接里面去看：https://ipset.netfilter.org/iptables-extensions.man.html#lbAD 。我估計應該有 60 個左右。

（6）跳轉到特點的目標 -j

我們設置的規則匹配上數據包后，總得干點啥是吧，不然不是白廢老大勁了么。當然， -j  不是必填項，但你非得說我就不想讓這個規則干具體的事情，也行！

我們可以給 -j 指定像 ACCEPT / DROP / QUEUE / RETURN 這樣的 netfilter 自帶的標準 target ，也可以給它指定我們自定義的鏈，除此之外還有若干個像 SNAT / REDIRECT / SET 這樣的擴展 target 可供我們使用。

比如下面這個例子中，就通過 -j KUBE-SERVICES 跳轉到自定義鏈 KUBE-SERVICES 去了。

-A INPUT -m conntrack --ctstate NEW -m comment --comment "kubernetes service portals" -j KUBE-SERVICES

流量通過 -j 跳轉到指定 target 之后會發生什么？這取決于 target 會對流量做啥：

• 比如對于 DROP target ，你也能猜出結局是什么：不但流量會丟棄了，它更加不會到達傳輸層（見后文）。
• 而對于 KUBE-SERVICES 這樣的 target，netfilter 會去執行這個鏈所定義的各種規則。

還記得前文我們說到的那默認的五條鏈嗎？它們既是默認的五條鏈更是 netfilter 施展拳腳的入口。從這些入口進去，netfilter 可能會調用到若干個自定義鏈以及串在鏈上的多種多樣的規則。假如所有的規則都不會下流量下死手，那么這些規則執行完后，就又回到入口處，也就是這五個默認的鏈。

2、不能單看 iptables

其實讀懂和理解 iptables 規則并不難，難的是理解 netfilter 是如何和 TCP/IP 協議棧緊密集成和協作以控制流量的行為的。你們見過機場行李托運輸送系統嗎？我們在值機口托運的行李會穿過行李分揀大廳的各條分叉，兜兜轉轉才來到飛機貨艙里面。

無論是入口流量還是本地進程產生的出口流量都如同我們在值機口托運的行李，而 netfilter 和 TCP/IP 協議棧則扮演了那個行李分揀系統。

圖 4：四表五鏈與協議棧集成細節  圖片來源：公眾號“開發內功修煉”

既然說到 netfilter 和 TCP/IP 協議棧則的緊密合作，那我們先看看協議棧部分。

圖中 ip_rcv() 是流量進入 IP 層的入口，ip_forward() 是轉發流量的入口，而流量通過 ip_output() 離開 IP 層。當 IP 層決定要把流量送往傳輸層的時候，它通過 ip_local_deliver() 來完成，相對應地，本地進程想要把數據發送出去，需要借助 __ip_local_out() 。注意所有這些函數都在 IP 層。

協議棧在執行這些不同的入口函數時，會有選擇地查看四表五鏈里面的鏈和相應的規則并執行這些規則。而規則里面所定義的 target 也反過來影響協議棧下一步的行為。

（1）過客和山海

從圖 4 我們可以看得出來，四表五鏈以及路由選擇其實是協議棧留出來給大家自由發揮的空間和口子。我們以圖中標號 ④ 這一步的 __ip_local_out() 為例，看看內核是如何與這些開口打交道的：

// net/ipv4/ip_output.cint __ip_local_out(struct net *net, struct sock *sk, struct sk_buff *skb){  // 省略其它代碼  return nf_hook(NFPROTO_IPV4, NF_INET_LOCAL_OUT,        net, sk, skb, NULL, skb_dst(skb)->dev,        dst_output);}
//include/net/dst.hstatic inline int dst_output(struct net *net, struct sock *sk, struct sk_buff *skb){  return INDIRECT_CALL_INET(skb_dst(skb)->output,   ip6_output, ip_output,   net, sk, skb);}
// net/ipv4/ip_output.cint ip_output(struct net *net, struct sock *sk, struct sk_buff *skb){  struct net_device *dev = skb_dst(skb)->dev, *indev = skb->dev;  // 省略其它代碼  return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING,     net, sk, skb, indev, dev,     ip_finish_output,     !(IPCB(skb)->flags & IPSKB_REROUTED));}

可以看到在這個函數的最后一步，協議棧就開始通過 nf_hook() 去遍歷 OUTPUT 鏈里面的規則了。這也是為什么我們說 OUTPUT 鏈是五鏈之一的原因。

nf_hook() 在遍歷完 OUTPUT 鏈之后，就調用 dst_output() 來送別網絡包。而網絡包從此則需獨自一人進入下一段旅程，過一會兒它將會遇到 ip_output() ，從那里離開 IP 層。

我們也可以看得出來對于發送流程， OUTPUT 鏈只是一個過客，網絡包在這一站稍作停留后還是要繼續奔赴山海，在后面的旅途中它會碰到協議棧其它代碼和其它鏈，比如在 ip_output() 里面，它會遇到 POSTROUTING 鏈。

（2）PREROUTING 鏈

讓我們把圖 4 仔細看一遍。

對于 ① ，當流量從外部進入網卡，ip_rcv() 負責將其接入 IP 層，PREROUTING 鏈先于路由選擇介入對流量的處理流程。比如下面的例子里，每一個原本想訪問 8022 端口的流量的 dest IP 和 dest Port 全部都被改成 127.0.0.1:22 。

# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8022 -j DNAT --to-destination 127.0.0.1:22

dest IP 和 dest Port 全部都改成 127.0.0.1:22 ，你很容易就猜到：在接下來的路由選擇這一步，協議棧會把修改過之后的流量通過 ② 送往本地進程。

如果 dest IP 和 dest Port 被改成了 39.156.66.10:443 呢？流量不會被送往本機，而是通過 ③ 被 forward 離開本機。當然前提是本機 forward 功能已經開啟了。

（3）INPUT 鏈

我們剛才說流量最終是通過 ip_local_deliver() 離開 IP 層并進入傳輸層的。不過在這之前，還有一個 INPUT 鏈等著它。流量能否被傳輸層處理還得看 INPUT 鏈是否允許。

比如對于下面這條規則，它存放在 INPUT 鏈的 filter 表里面，當發現流量是 tcp 協議，且訪問的是本機 22 端口，就把流量丟棄掉，說白話就是不允許任何人通過 ssh 訪問本機。于是對于任何進來的流量，② 這條路就算走到頭了。ip_local_deliver() 不會被執行，sshd 也就沒有機會收到這個請求。

iptables -t filter -I INPUT -p tcp --dport 22 -j DROP

又或者如果一切都很正常，不出意外的話，位于傳輸層的函數 tcp_v4_rcv() 會接收到這個可能已經被修改過之后的流量，從此流量開始了它在傳輸層的旅程。

（4）FORWARD 鏈

當路由選擇決定要把流量 forward 后，會調用 ip_forward() 開始后續的 forward 處理流程，這個流程如 ③ 所示。如果你喜歡，你可以在 FORWARD 鏈中加入你喜歡的規則來控制流量從命運。比如下面的例子：

-A FORWARD -m comment --comment "kubernetes forwarding rules" -j KUBE-FORWARD-A KUBE-FORWARD -m comment --comment "kubernetes forwarding rules" -m mark --mark 0x4000/0x4000 -j ACCEPT

（5）OUTPUT 鏈

① ② ③ 這三條數據流里面涉及到的三個鏈都是因網卡接收到了外部的流量引起的，它們都是被動被執行。而 OUTPUT 鏈則是因為本地程序向主動發送流量而觸發執行流程。

當網絡包從傳輸層通過 tcp_write_xmit() 來到 IP 層時，首先迎接它的還是路由選擇。這一步會產生兩個重要的決定：

• next-hop 是誰，也即由誰來接收網絡包
• 從本機哪個 interface 離開

你可能會困惑，不是由應用程序寫好的 dest IP 來接收網絡包嗎？沒錯，不過那是最終接收者，在這中間還會有若干個設備會經手并傳遞這個網絡包。這就好像你從南京快遞一個 iPhone 給遠在北京的女友。當然最終是你的女友負責接收、拆開這個包裹，但在她拿到包裹之前，有非常多的快遞站中轉站、快遞小哥也會觸碰到它。這里所說的 next-hop 就是負責收取快遞的第一個人。

如果這臺設備有多個網卡的話，得選擇其中一個網卡來將網絡包傳送出去。

ip_output() 負責將網絡包送離 IP 層，但且慢，看到 ④ 那里的 OUTPUT 鏈了嗎？是的，這次輪到它大顯身手了。我們可以在這里對包做一次 SNAT ，使得它離開本機的時候，源地址使用本機的 IP 地址。關于 OUTPUT 鏈具體的例子我們留到最后聊 istio route 的時候再細說。

3、通過 loopback 通信

問大家一個問題：現有下面這兩個網絡通信場景：

場景一：本機同一個 network namespace 下面的兩個進程之間通過 loopback(后文簡稱 lo) 設備進行網絡通信，如圖 5 所示。

場景二：一個局域網內，連接在同一個交換機上的兩臺主機上的兩個進程相互進行網絡通信，如圖 6 所示。

這兩個場景下，除去鏈路層設備的不同所帶來的二層收發數據的區別外，內核協議棧對數據包的處理過程有本質的不同嗎？從圖中你也可以看出來，無論是圖 5 還是圖 6，數據均需要走完如下的過程：

發端應用層 -> 發端傳輸層 -> 發端網絡層 -> 發端鏈路層 ->（物理層數據收發）-> 收端鏈路層 -> 收端網絡層 -> 收端傳輸層 -> 收端應用層

對于圖 6，上述這個過程大家應該沒有任何異議。重點是對于圖 5 所示的場景：即便通過 loopback 設備通信，網絡包還是要兩次完整地穿越協議棧。注意我這里的用詞：完整地。理解這點非常重要，因為后面要用。

圖 5：通信場景一：兩個進程相互之間通過 loopback 設備通信

圖 6：通信場景二：LAN 通信

4、簡單過下 istio route

二哥需要強調一個重點：圖 7 所示的包括四表五鏈、conntrack 表、供路由選擇的路由表、接口 eth0 和 loopback 在內的信息都是 network namespace 的一部分。對于一個進程來說，這些要素其實就構成了它發起和響應網絡請求的基本環境。在正常情況下，一個 Pod 里面所有的 container 都共享一個 network ns，也就共享著這個基本環境。

一個 network ns 如同一座圍城，圍住了所有的數據。

我們都知道 Linux 支持多個 network namespace，這也就意味著類似這樣的基本環境會有若干份。當然，在每個基本環境里面，像四表五鏈、路由表之類的數據各有千秋。

我們可以將 TCP/IP 協議棧看成是程序的代碼部分，而將上述的基本環境看成是程序的數據部分。很顯然 TCP/IP 棧應該是被這個 OS 上所有人共享的，無論是進程還是容器，甚至是基于 qemu-kvm 的虛擬機都共享著宿主機的協議棧，但 network ns 所圍起來的數據卻是各個 network ns 獨享的。

圖 7：Envoy 劫持網絡流量全景圖

下面我們將以 App container 想要訪問 www.baidu.com 443 端口為例來帶大家過一下 istio route 。

這個過程在圖 7 上來看，就是始于 App container internal logic 的，標號為 ⑨ ~ ? ~ ? 的數據流。我們沿著箭頭的方向會發現網絡包被透明地劫持到了 Envoy 的 Outbound hanlder 15001 端口。我們重點分析 Envoy 是如何通過 iptables 來做到這一點的。

（1）相關 iptables

首先我們來看下與這個流程相關的 iptables 。為節省篇幅，突出重點，二哥省去了其余的部分，只保留了 OUTPUT 鏈及其會調用到的自定義鏈。

# View the details of the rule configuration in the NAT table.$ iptables -t nat -L -v
# OUTPUT chain: jumps all outbound packets to the ISTIO_OUTPUT chain.Chain OUTPUT (policy ACCEPT 79 packets, 6761 bytes)pkts bytes target       prot opt in     out     source               destination15   900 ISTIO_OUTPUT tcp  --  any    any     anywhere             anywhere
# POSTROUTING CHAIN: All packets must first enter the POSTROUTING chain when they leave the network card, and the kernel determines whether they need to be forwarded out according to the packet destination.Chain POSTROUTING (policy ACCEPT 79 packets, 6761 bytes)pkts bytes target     prot opt in     out     source               destination
# ISTIO_IN_REDIRECT chain: jumps all inbound traffic to the local 15006 port, thus successfully blocking traffic to the sidecar.Chain ISTIO_IN_REDIRECT (3 references)pkts bytes target     prot opt in     out     source               destination0     0 REDIRECT    tcp  --  any    any     anywhere             anywhere             redir ports 15006
# ISTIO_OUTPUT chain: see the details bellowChain ISTIO_OUTPUT (1 references)pkts bytes target     prot opt in     out     source               destination0     0 RETURN      all  --  any    lo      127.0.0.6            anywhere0     0 ISTIO_IN_REDIRECT  all  --  any    lo      anywhere             !localhost           owner UID match 13370     0 RETURN      all  --  any    lo      anywhere             anywhere             ! owner UID match 133715   900 RETURN     all  --  any    any     anywhere             anywhere             owner UID match 13370     0 ISTIO_IN_REDIRECT  all  --  any    lo      anywhere             !localhost           owner GID match 13370     0 RETURN      all  --  any    lo      anywhere             anywhere             ! owner GID match 13370     0 RETURN      all  --  any    any     anywhere             anywhere             owner GID match 13370     0 RETURN      all  --  any    any     anywhere             localhost0     0 ISTIO_REDIRECT  all  --  any    any     anywhere             anywhere
# ISTIO_REDIRECT chain: redirects all traffic to Sidecar (i.e. local) port 15001.Chain ISTIO_REDIRECT (1 references)pkts bytes target     prot opt in     out     source               destination0     0  REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 15001

首先我們看到這段輸出是用命令 iptables -t nat -L -v 得到的。你看到 -t nat 了嗎？這表示這些規則全部都存放在 nat 表里面。我相信大家對 NAT 有所耳聞，看到它也就大概猜得出來幾分：既然這些規則是與 NAT 表相關的，那么它們干的事情也就涉及到修改 IP 地址或端口這樣的操作。

我把這些規則之間的關系用圖 8 表示出來了。我們來看看它們是如何協作的。

圖 8：istio route 自定義鏈 ISTIO_OUTPUT 細節

（2）協作細節

首先當 App cotainer 訪問 baidu.com 時，請求從傳輸層出來后，首先需要經過一次路由。這個時候協議棧也僅僅知道這個包的目的 IP（39.156.66.10） 和 目的端口（443），還不知道它的二層信息是什么。為什么呢？得經過路由后，才能知道包需要從本地哪個接口離開，以及誰是 next-hop ，也只有當知曉了這些信息后，才能填充二層頭的 src MAC 和 dest MAC。因為 IP 地址是與接口綁在一起的，所以從哪里接口離開也就決定了 src IP 是什么。

路由選擇細節就不細講了。我們先把它看作一個黑盒子，經過它之后，協議棧做了一個決定：去 39.156.66.10 的話，得從接口 eth0 離開。再強調一次，eth0 位于 App cotainer 所在的 network namespace 里面。

按照前文所述的協議棧和 netfilter 配合流程，我們現在知道路由選擇后，緊接著需要執行 OUTPUT 鏈里面的規則。

? OUTPUT 鏈是五大入口鏈之一，可在這里，它啥都沒干，直接把活外包給自定義鏈 ISTIO_OUTPUT 了。我們可以看到鏈 ISTIO_OUTPUT 上掛了 9 個規則。

圖 9：ISTIO_OUTPUT 鏈上的 9 個規則

規則 1，2，3，5，6 都不滿足條件，因為我們需要從接口 eth0 離開，而不是 lo ，當然這兩個接口都屬于這個 Pod 所使用的 network ns。

規則 4，7 對目的地的 owner UID 和 GID 做了限制，不符合我們的場景。

規則 8 的目的地是 localhost，而我們想要去 39.156.66.10。很抱歉，完美錯過。

最后就剩規則 9 了。這個規則非常粗礦，啥都行，碰到這個它，大家就只能全部乖乖地跳轉到自定義鏈 ISTIO_REDIRECT 了。

? 這一步表示了這樣的跳轉過程。

? 自定義鏈 ISTIO_REDIRECT 也是人狠話不多。只要傳輸層是 TCP 的流量，全部統一 REDIRECT 到 127.0.0.1:10051 。

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

我們來看看 target REDIRECT 會對流量干啥事。

REDIRECT
This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only called from those chains. It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface (locally-generated packets are mapped to the localhost address, 127.0.0.1 for IPv4 and ::1 for IPv6).

說白了，它會把 dest IP 和 dest Port 改成 127.0.0.1:15001 。這好理解，畢竟只有這樣，在圖 8 ? 處路由的時候， IP 層才會把從 App container 出來的流量路由至 listen 在 15001 的 Outbound hanlder 去處理。

這一步做完后，從 ? 開始的 OUTPUT 鏈遍歷執行過程就結束了。那結束之后下一步協議棧要干什么呢？

跟著 ? ? ? ? ? 走一遍，你會知道全部的答案。不過注意看 ? 那里所標示的目的 IP 和目的端口，它們已經被改掉了。既然目的 IP 已經被改成了 127.0.0.1 了，那在 ? ? 那里發生的就是前文所述的通過 loopback 通信所涉及的技術細節了。