在此之前

在此之前，我只關注 Shadowsocks 的 TCP 轉發，就算連 DNS 查詢我也是使用 TCP。由於 TCP 是有狀態的，穿越 NAT 基本沒有問題。

代理 UDP

問題出現在我在 Steam 購買了 PUBG 這款遊戲之後，不論是遊戲還是使用 Discord 的遊戲語音都需要使用到 Shadowsocks 的 UDP 代理功能。實現也有兩種方法，在 Windows 平台下有 SSTap，或者使用 Linux 作為網關，使用 ss-redir 配合 TPROXY 代理 UDP。

STUN 失敗與分析

就這樣使用了大半年遊戲一直很流暢，直到某一天使用 Facetime Audio 感到不流暢，由於當時關閉了代理，而使用 Facetime Audio 的兩台設備均在中國大陸，便猜測是走了 Apple 的 relay server。但仔細想了一下並不應該，兩台設備均在一層 NAT 之後，只要有一台設備是 Full cone NAT，基於 UDP 是可以實現 P2P 通信的。其中一台設備的環境是路由器有公網 IP，運行 Linux 作為 NAT 網關，NAT 測試是 Port-Restricted cone NAT，加上路由器和應用程式均支援 UPnP，是可以達到 Full cone NAT 的級別的。

一番調研

好像有什麼不對？經過後來一番研究，才發現上面的猜想完全錯誤了。

首先 Linux 默認是不支持 UPnP，需要安裝額外的程式。OpenWrt 一類的路由器系統會自帶 miniupnp 程式，但不會默認開啟。

此外，更大的誤會是，Linux 內核的 NAT 是 Symmetric NAT，但一些基於 Linux 的路由器系統通過 patch 實現了 Full cone NAT。¹

造成我判斷錯誤的原因是使用的 STUN 檢測工具對 NAT 類型的標準和 Linux 稍有差異。

brief introduction of NAT type

關於 NAT type，主要有四種類型。²

假設有四台設備：

• A 機器在私網 192.168.0.4
• NAT 伺服器 210.21.12.140
• B 機器在公網 210.15.27.166
• C 機器在公網 210.15.27.140

現在，A 機器連線過 B 機器，假設是 A（192.168.0.4:5000）到 NAT（轉換後 210.21.12.140:8000）到 B（210.15.27.166:2000）。此外 A 從來沒有和 C 通訊過。則對於不同型別的 NAT，有下列不同的結果：

Full Cone NAT

C 發資料到 NAT（210.21.12.140:8000），NAT 會將資料包送到 A（192.168.0.4:5000）。因為 NAT 上已經有了 192.168.0.4:5000 到 210.21.12.140:8000 的對映。

Restricted Cone

C 無法和 A 通訊，因為 A 從來沒有和 C 通訊過，NAT 將拒絕 C 試圖與 A 連線的動作。但 B 可以通過 210.21.12.140:8000 與 A 的 192.168.0.4:5000 通訊，且這裡 B 可以使用任何埠與 A 通訊。如：210.15.27.166:2001 到 210.21.12.140:8000，NAT 會送到 A 的 5000 埠上。

Port Restricted Cone

C 無法與 A 通訊，因為 A 從來沒有和 C 通訊過。而 B 也只能用它的 210.15.27.166:2000 與 A 的 192.168.0.4:5000 通訊，因為 A 也從來沒有和 B 的其他埠通訊過。該型別 NAT 是埠受限的。

上面 3 種類型，統稱為 Cone NAT，有一個共同點：只要是從同一個內部地址和埠出來的包，NAT 都將它轉換成同一個外部地址和埠。

Symmetric NAT

只要是從同一個內部地址和埠出來，且到同一個外部目標地址和埠，則 NAT 也都將它轉換成同一個外部地址和埠；但如果從同一個內部地址和埠出來，到另一個外部目標地址和埠，則 NAT 將使用不同的對映，轉換成不同的埠。而且和 Port Restricted Cone 一樣，只有曾經收到過內部地址發來包的外部地址，才能通過 NAT 對映後的地址向該內部地址發包。

Cone NAT，有一個共同點：只要是從同一個內部地址和埠出來的包，NAT 都將它轉換成同一個外部地址和埠。Symmetric NAT 如果從同一個內部地址和埠出來，到另一個外部目標地址和埠，則 NAT 將使用不同的對映，轉換成不同的埠。

iptables 與 STUN

iptables 在轉換地址時，遵循如下兩個原則：

• 儘量不去修改源埠，也就是說，IP 偽裝後的源埠儘可能保持不變。
• 更為重要的是，IP 偽裝後只需保證偽裝後的（源地址，源埠，目標地址，目標埠）唯一即可。

仍以前例說明如下。

A 機器連線過 B 機器，假使是 A（192.168.0.4:5000）到 NAT（轉換後 210.21.12.140:5000）到 B（210.15.27.166:2000），此處 NAT 遵循原則，換後埠沒有改變。

如果此時 A 機器（192.168.0.4:5000）還想連線 C 機器 （210.15.27.140:2000），則 NAT 上產生一個新的對映，但對應的轉換仍然有可能為 A（192.168.0.4:5000）到 NAT（轉換後 210.21.12.140:5000）到 C（210.15.27.140:2000）。這是因為 NAT 到 B（210.15.27.166:2000）和 NAT 到 C（210.15.27.140:2000）這兩個目標地址不重複。因此，對於 iptables 來說，這是允許的。

在該例中，表面上看起來 iptables 似乎不屬於 Symmetric NAT，因為它看起來不符合 Symmetric NAT 的要求：如果從同一個內部地址和埠出來，是到另一個目標地址和埠，則 NAT 將使用不同的對映，轉換成不同的埠。 相反，倒是符合除 Symmetric NAT 外的三種 Cone NAT 的要求：從同一個內部地址和埠出來的包，NAT 都將它轉換成同一個外部地址和埠。加上 iptables 具有埠受限的屬性，所以好多檢測工具就把 iptables 報告為 Port Restricted Cone 了。

現在增加 D 機器在私網（192.168.0.5）。

A 機器連線過 B 機器，假使是 A（192.168.0.4:5000）到 NAT（轉換後 210.21.12.140:5000）到 B（210.15.27.166:2000）。

D 機器連線過 C 機器，假使是 D（192.168.0.5:5000）到 NAT（轉換後 210.21.12.140:5000）到 C（210.15.27.140:2000）。

如果此時 A 機器（192.168.0.4:5000）還想連線 C 機器 （210.15.27.140:2000），則 NAT 上產生一個新的對映，但對應的轉換則變為 A（192.168.0.4:5000）到 NAT（轉換後 210.21.12.140:5001）到 C（210.15.27.140:2000）。

下面，我們再來分析一下 iptables 的埠受限的屬性。

A 機器連線過 B 機器，假使是 A（192.168.0.4:5000）到 NAT（轉換後 210.21.12.140:5000）到 B（210.15.27.166:2000）。

D 機器連線過 C 機器，假使是 D（192.168.0.5:5000）到 NAT（轉換後 210.21.12.140:5000）到 C（210.15.27.140:2000）。

現假設 iptables 不具有埠受限的屬性，則另一 E 機器在公網 （210.15.27.153:2000）向 210.21.12.140:5000 發包，應該能夠發到內部機器上。但事實是，當這個包到達 NAT（210.21.12.140:5000）時，NAT 將不知道把這個包發給 A（192.168.0.4:5000）還是 D（192.168.0.5:5000）。顯然該包只能丟棄，至此足以證明 iptables 具有埠受限的屬性。

所以，iptables 是貨真價實的 Symmetric NAT。³

另闢蹊徑得 Full Cone NAT

如何在不修改 Linux 內核的情況下得到 Full Cone NAT？

除了 DMZ ，還可以使用 ss-redir 配合 TPROXY。Shadowsocks 在設計 UDP relay 之初就考慮到這個問題了。⁴

Long Live Shadowsocks!

1. https://blog.chionlab.moe/2018/02/09/full-cone-nat-with-linux/↩

2. 网络地址转换↩

3. https://blog.csdn.net/u011245325/article/details/9294229↩

4. https://github.com/shadowsocks/shadowsocks-libev/issues/259↩