一文解析NAT 穿透的技術原理

譯者序

本文翻譯自 2020 年的一篇英文博客：How NAT traversal works。 ? ? 設想這樣一個問題：在北京和上海各有一臺局域網(wǎng)的機器（例如一臺是家里的臺式機，一臺是連接到店鋪WiFi 的筆記本），二者都是私網(wǎng) IP 地址，但可以訪問公網(wǎng)，?如何讓這兩臺機器通信呢？ ? 既然二者都能訪問公網(wǎng)，那最簡單的方式就是在公網(wǎng)上架設一個中繼服務器：兩臺機器分別連接到中繼服務，后者完成雙向轉(zhuǎn)發(fā)。這種方式有很大的性能開銷，而且中繼服務器很容易成為瓶頸。 ?

有沒有辦法不用中繼，讓兩臺機器直接通信呢？ ? *Tailscale是一家軟件公司，開發(fā)了一個開源軟件定義的mesh VPN和基于Web的管理服務。同時，該公司用于構(gòu)建安全網(wǎng)絡的零配置 VPN也名Tailscale。 *由于譯者水平有限，本文不免存在遺漏或錯誤之處。如有疑問，請查閱原文。以下是譯文。

引言

背景：IPv4 地址短缺，引入 NAT

全球 IPv4 地址早已不夠用，因此人們發(fā)明了 NAT（網(wǎng)絡地址轉(zhuǎn)換）來緩解這個問題。 ? 簡單來說，大部分機器都使用私有 IP 地址，如果它們需要訪問公網(wǎng)服務，那么：

出向流量：需要經(jīng)過一臺 NAT 設備，它會對流量進行 SNAT，將私有 srcIP+Port 轉(zhuǎn) 換成 NAT 設備的公網(wǎng) IP+Port（這樣應答包才能回來），然后再將包發(fā)出去；

應答流量（入向）：到達 NAT 設備后進行相反的轉(zhuǎn)換，然后再轉(zhuǎn)發(fā)給客戶端。

整個過程對雙方透明。 ? 以上是本文所討論問題的基本背景。 ?

需求：兩臺經(jīng)過 NAT 的機器建立點對點連接

在以上所描述的 NAT 背景下，我們從最簡單的問題開始：如何在兩臺經(jīng)過 NAT 的機器之間建立點對點連接（直連）。如下圖所示： ?

直接用機器的 IP 互連顯然是不行的，因為它們都是私有 IP（例如 192.168.1.x）。在 Tailscale 中，我們會建立一個 WireGuard 隧道?來解決這個問題 —— 但這并不是太重要，因為我們將過去幾代人努力都整合到了一個工具集，?這些技術廣泛適用于各種場景。例如， ?

WebRTC 使用這些技術在瀏覽器之間完成 peer-to-peer 語音、視頻和數(shù)據(jù)傳輸；

VoIP 電話和一些視頻游戲也使用類似機制，雖然不是所有情況下都很成功。

方案：NAT 穿透

＞兩個必備前提：UDP + 能直接控制 socket ? 如果想設計自己的協(xié)議來實現(xiàn) NAT 穿透，那必須滿足以下兩個條件： ?

協(xié)議應該基于 UDP

理論上用 TCP 也能實現(xiàn)，但它會給本已相當復雜的問題再增加一層復雜性，甚至還需要定制化內(nèi)核，取決于你想實現(xiàn)到什么程度。本文接下來都將關注在 UDP 上。 ? 如果考慮 TCP 是想在 NAT 穿透時獲得面向流的連接（ stream-oriented connection），可以考慮用 QUIC 來替代，它構(gòu)建在 UDP 之上，因此我們能將關注點放在 UDP NAT 穿透，而仍然能獲得一個很好的流協(xié)議（stream protocol）。 ?

對收發(fā)包的 socket 有直接控制權(quán)

例如，從經(jīng)驗上來說，無法基于某個現(xiàn)有的網(wǎng)絡庫實現(xiàn) NAT 穿透，因為我們必須在使用的“主要”協(xié)議之外，發(fā)送和接收額外的數(shù)據(jù)包。 ? 某些協(xié)議（例如 WebRTC）將 NAT 穿透與其他部分緊密集成。但如果你在構(gòu)建自己的協(xié)議，?建議將 NAT 穿透作為一個獨立實體，與主協(xié)議并行運行，二者僅僅是共享 socket 的關系，如下圖所示，這將帶來很大幫助：

＞保底方式：中繼 ? 在某些場景中，直接訪問 socket 這一條件可能很難滿足。 ? 退而求其次的一個方式是設置一個 local proxy（本地代理），主協(xié)議與這個 proxy 通信，后者來完成 NAT 穿透，將包中繼（relay）給對端。這種方式增加了一個額外的間接層，但好處是： ?

仍然能獲得 NAT 穿透，

不需要對已有的應用程序做任何改動。

挑戰(zhàn)：有狀態(tài)防火墻和 NAT 設備

有了以上鋪墊，下面就從最基本的原則開始，一步步看如何實現(xiàn)一個企業(yè)級的 NAT 穿透方案。 ? 我們的目標是：在兩個設備之間通過 UDP 實現(xiàn)雙向通信，有了這個基礎，上層的其他協(xié)議（WireGuard, QUIC, WebRTC 等）就能做一些更酷的事情。 ? 但即便這個看似最基本的功能，在實現(xiàn)上也要解決兩個障礙： ?

有狀態(tài)防火墻

NAT 設備

穿透防火墻

有狀態(tài)防火墻是以上兩個問題中相對比較容易解決的。實際上，大部分 NAT 設備都自帶了一個有狀態(tài)防火墻，因此要解決第二個問題，必須先解決有第一個問題。 ? 有狀態(tài)防火墻具體有很多種類型，有些你可能見過： ?

Windows Defender firewall

Ubuntu’s ufw (using iptables/nftables)

BSD/macOS?pf

AWS Security Groups（安全組）

有狀態(tài)防火墻

＞默認行為（策略） ? 以上防火墻的配置都是很靈活的，但大部分配置默認都是如下行為： ?

允許所有出向連接（allows all “outbound” connections）

禁止所有入向連接（blocks all “inbound” connections）

可能有少量例外規(guī)則，例如 allowing inbound SSH。 ? ＞如何區(qū)分入向和出向包 ? 連接（connection）和方向（direction）都是協(xié)議設計者頭腦中的概念，到了物理傳輸層，每個連接都是雙向的；允許所有的包雙向傳輸。那防火墻是如何區(qū)分哪些是入向包、哪些是出向包的呢？這就要回到“有狀態(tài)”（stateful）這三個字了：有狀態(tài)防火墻會記錄它看到的每個包，當收到下一個包時，會利用這些信息（狀態(tài)）來判斷應該做什么。 ? 對UDP 來說，規(guī)則很簡單：如果防火墻之前看到過一個出向包（outbound），就會允許相應的入向包（inbound）通過，以下圖為例： ?

? 筆記本電腦中自帶了一個防火墻，當該防火墻看到從這臺機器出去的?2.2.2.2:1234 -> 5.5.5.5:5678?包時，就會記錄一下：5.5.5.5:5678 -> 2.2.2.2:1234?入向包應該放行。?這里的邏輯是：我們信任的世界（即筆記本）想主動與?5.5.5.5:5678?通信，因此應該放行（allow）其回包路徑。 ? 某些非常寬松的防火墻只要看到有從 2.2.2.2:1234 出去的包，就會允許所有從外部進入 2.2.2.2:1234 的流量。這種防火墻對我們的 NAT 穿透來說非常友好，但已經(jīng)越來越少見了。 ?

防火墻朝向（face-off）與穿透方案

＞防火墻朝向相同 ? 場景特點：服務端 IP 可直接訪問 ? 在 NAT 穿透場景中，以上默認規(guī)則對 UDP 流量的影響不大 —— 只要路徑上所有防火墻的“朝向”是一樣的。一般來說，從內(nèi)網(wǎng)訪問公網(wǎng)上的某個服務器都屬于這種情況。 ? 我們唯一的要求是：連接必須是由防火墻后面的機器發(fā)起的。這是因為在它主動和別人通信之前，沒人能主動和它通信，如下圖所示： ? 穿透方案：客戶端直連服務端，或 hub-and-spoke 拓撲

? 但上圖是假設了通信雙方中，其中一端（服務端）是能直接訪問到的。在 VPN 場景中，這就形成了所謂的 hub-and-spoke 拓撲：中心的 hub 沒有任何防火墻策略，誰都能訪問到；防火墻后面的 spokes 連接到 hub。如下圖所示：

＞防火墻朝向不同

場景特點：服務端 IP 不可直接訪問 ? 但如果兩個“客戶端”想直連，以上方式就不行了，此時兩邊的防火墻相向而立，如下圖所示：

根據(jù)前面的討論，這種情況意味著：兩邊要同時發(fā)起連接請求，但也意味著兩邊都無法發(fā)起有效請求，因為對方先發(fā)起請求才能在它的防火墻上打開一條縫讓我們進去！如何破解這個問題呢？一種方式是讓用戶重新配置一邊或兩邊的防火墻，打開一個端口，允許對方的流量進來。 ?

這顯然對用戶不友好，在像 Tailscale 這樣的 mesh 網(wǎng)絡中的擴展性也不好，在 mesh 網(wǎng)絡中，我們假設對端會以一定的粒度在公網(wǎng)上移動；

此外，在很多情況下用戶也沒有防火墻的控制權(quán)限：例如在咖啡館或機場中，連接的路由器是不受你控制的（否則你可能就有麻煩了）。

因此，我們需要尋找一種不用重新配置防火墻的方式。 ? 穿透方案：兩邊同時主動建連，在本地防火墻為對方打開一個洞 ? 解決的思路還是先重新審視前面提到的有狀態(tài)防火墻規(guī)則： ?

對于 UDP，其規(guī)則（邏輯）是：包必須先出去才能進來（packets must flow out before packets can flow back in）。

注意，這里除了要滿足包的 IP 和端口要匹配這一條件之外，并沒有要求包必須是相關的（related）。換句話說，只要某些包帶著正確的源和目的地址出去了，任何看起來像是響應的包都會被防火墻放進來?—— 即使對端根本沒收到你發(fā)出去的包。

因此，要穿透這些有狀態(tài)防火墻，我們只需要共享一些信息：讓兩端提前知道對方使用的 ip:port： ?

手動靜態(tài)配置是一種方式，但顯然擴展性不好；

我們開發(fā)了一個 coordination server，以靈活、安全的方式來同步 ip:port 信息。

有了對方的 ip:port 信息之后，兩端開始給對方發(fā)送 UDP 包。在這個過程中，我們預料到某些包將會被丟棄。因此，雙方必須要接受某些包會丟失的事實，因此如果是重要信息，你必須自己準備好重傳。對 UDP 來說丟包是可接受的，但這里尤其需要接受。 ? 來看一下具體建連（穿透）過程： ? 1）如圖所示，筆記本出去的第一包，2.2.2.2:1234 -> 7.7.7.7:5678，穿過 Windows Defender 防火墻進入到公網(wǎng)。 ?

? 對方的防火墻會將這個包攔截掉，因為它沒有?7.7.7.7:5678 -> 2.2.2.2:1234?的流量記錄。但另一方面，Windows Defender 此時已經(jīng)記錄了出向連接，因此會允許?7.7.7.7:5678 -> 2.2.2.2:1234?的應答包進來。 ? 2）接著，第一個?7.7.7.7:5678 -> 2.2.2.2:1234?穿過它自己的防火墻到達公網(wǎng)。

? 到達客戶端側(cè)時，Windows Defender 認為這是剛才出向包的應答包，因此就放行它進入了！?此外，右側(cè)的防火墻此時也記錄了：2.2.2.2:1234 -> 7.7.7.7:5678?的包應該放行。 ? 3）筆記本收到服務器發(fā)來的包之后，發(fā)送一個包作為應答。這個包穿過 Windows Defender 防火墻和服務端防火墻（因為這是對服務端發(fā)送的包的應答包），達到服務端。

成功！這樣我們就建立了一個穿透兩個相向防火墻的雙向通信連接。而初看之下，這項任務似乎是不可能完成的。 ?

關于穿透防火墻的一些思考

穿透防火墻并非永遠這么輕松，有時會受一些第三方系統(tǒng)的間接影響，需要仔細處理。那穿透防火墻需要注意什么呢？重要的一點是：通信雙方必須幾乎同時發(fā)起通信，這樣才能在路徑上的防火墻打開一條縫，而且兩端還都是活著的。 ? ＞雙向主動建連：旁路信道 ? 如何實現(xiàn)“同時”呢？一種方式是兩端不斷重試，但顯然這種方式很浪費資源。假如雙方都知道何時開始建連就好了。 ? 這聽上去是雞生蛋、蛋生雞的問題了：雙方想要通信，必須先提前通個信。 ? 但實際上，我們可以通過旁路信道（side channel）來達到這個目的，并且這個旁路信道并不需要很 fancy：它可以有幾秒鐘的延遲、只需要傳送幾 KB 的信息，因此即使是一個配置非常低的虛擬機，也能為幾千臺機器提供這樣的旁路通信服務。 ?

在遙遠的過去，我曾用 XMPP 聊天消息作為旁路，效果非常不錯。

另一個例子是 WebRTC，它需要你提供一個自己的“信令信道”（signalling channel，這個詞也暗示了 WebRTC 的 IP telephony ancestry），并將其配置到 WebRTC API。

在 Tailscale，我們的協(xié)調(diào)服務器（coordination server）和 DERP (Detour Encrypted Routing Protocol) 服務器集群是我們的旁路信道。

＞非活躍連接被防火墻清理 ? 有狀態(tài)防火墻內(nèi)存通常比較有限，因此會定期清理不活躍的連接（UDP 常見的是 30s），因此要保持連接 alive 的話需要定期通信，否則就會被防火墻關閉，為避免這個問題，我們 ?

要么定期向?qū)Ψ桨l(fā)包來 keepalive；

要么有某種帶外方式來按需重建連接。

＞問題都解決了？不，挑戰(zhàn)剛剛開始 ? 對于防火墻穿透來說，我們并不需要關心路徑上有幾堵墻?—— 只要它們是有狀態(tài)防火墻且允許出向連接，這種同時發(fā)包（simultaneous transmission）機制就能穿透任意多層防火墻。這一點對我們來說非常友好，因為只需要實現(xiàn)一個邏輯，然后能適用于任何地方了。 ? …對嗎？ ? 其實，不完全對。這個機制有效的前提是：我們能提前知道對方的 ip:port。而這就涉及到了我們今天的主題：NAT，它會使前面我們剛獲得的一點滿足感頓時消失。 ? 下面，進入本文正題。 ?

NAT 的本質(zhì)

NAT 設備與有狀態(tài)防火墻

可以認為 NAT 設備是一個增強版的有狀態(tài)防火墻，雖然它的增強功能對于本文場景來說并不受歡迎：除了前面提到的有狀態(tài)攔截/放行功能之外，它們還會在數(shù)據(jù)包經(jīng)過時修改這些包。 ?

NAT 穿透與 SNAT/DNAT

具體來說，NAT 設備能完成某種類型的網(wǎng)絡地址轉(zhuǎn)換，例如，替換源或目的 IP 地址或端口。 ?

討論連接問題和 NAT 穿透問題時，我們只會受 source NAT —— SNAT 的影響；

DNAT 不會影響 NAT 穿透。

SNAT 的意義：解決 IPv4 地址短缺問題

SNAT 最常見的使用場景是將很多設備連接到公網(wǎng)，而只使用少數(shù)幾個公網(wǎng) IP。例如對于消費級路由器，會將所有設備的（私有） IP 地址映射為單個連接到公網(wǎng)的 IP 地址。 ? 這種方式存在的意義是：我們有遠多于可用公網(wǎng) IP 數(shù)量的設備需要連接到公網(wǎng)，（至少對 IPv4 來說如此，IPv6 的情況后面會討論）。NAT 使多個設備能共享同一 IP 地址，因此即使面臨 IPv4 地址短缺的問題，我們?nèi)匀荒懿粩鄶U張互聯(lián)網(wǎng)的規(guī)模。 ?

SNAT 過程：以家用路由器為例

假設你的筆記本連接到家里的 WiFi，下面看一下它連接到公網(wǎng)某個服務器時的情形： ? 1）筆記本發(fā)送 UDP packet?192.168.0.20:1234 -> 7.7.7.7:5678。

這一步就好像筆記本有一個公網(wǎng) IP 一樣，但源地址 192.168.0.20?是私有地址，只能出現(xiàn)在私有網(wǎng)絡，公網(wǎng)不認，收到這樣的包時它不知道如何應答。 ? 2）家用路由器出場，執(zhí)行 SNAT。 ? 包經(jīng)過路由器時，路由器發(fā)現(xiàn)這是一個它沒有見過的新會話（session）。它知道 192.168.0.20?是私有 IP，公網(wǎng)無法給這樣的地址回包，但它有辦法解決： ?

在它自己的公網(wǎng) IP 上挑一個可用的 UDP 端口，例如?2.2.2.2:4242，

然后創(chuàng)建一個 NAT mapping：192.168.0.20:1234 <--> 2.2.2.2:4242，

然后將包發(fā)到公網(wǎng)，此時源地址變成了 2.2.2.2:4242 而不是原來的 192.168.0.20:1234。因此服務端看到的是轉(zhuǎn)換之后地址，

接下來，每個能匹配到這條映射規(guī)則的包，都會被路由器改寫 IP 和端口。

? 3）反向路徑是類似的，路由器會執(zhí)行相反的地址轉(zhuǎn)換，將 2.2.2.2:4242 變回 192.168.0.20:1234。對于筆記本來說，它根本感知不知道這正反兩次變換過程。 ? 這里是拿家用路由器作為例子，但辦公網(wǎng)的原理是一樣的。不同之處在于，辦公網(wǎng)的 NAT 可能有多臺設備組成（高可用、容量等目的），而且它們有不止一個公網(wǎng) IP 地址可用，因此在選擇可用的公網(wǎng) ip:port 來做映射時，選擇空間更大，能支持更多客戶端。 ?

SNAT 給穿透帶來的挑戰(zhàn)

現(xiàn)在我們遇到了與前面有狀態(tài)防火墻類似的情況，但這次是 NAT 設備：通信雙方不知道對方的 ip:port 是什么，因此無法主動建連，如下圖所示：

但這次比有狀態(tài)防火墻更糟糕，嚴格來說，在雙方發(fā)包之前，根本無法確定（自己及對方的）ip:port 信息，因為?只有出向包經(jīng)過路由器之后才會產(chǎn)生 NAT mapping（即，可以被對方連接的 ip:port 信息）。 ? 因此我們又回到了與防火墻遇到的問題，并且情況更糟糕：雙方都需要主動和對方建連，但又不知道對方的公網(wǎng)地址是多少，只有當對方先說話之后，我們才能拿到它的地址信息。 ? 如何破解以上死鎖呢？這就輪到 STUN 登場了。 ? 穿透 “NAT+防火墻”：STUN (Session Traversal Utilities for NAT) 協(xié)議 ? STUN 既是一些對 NAT 設備行為的詳細研究，也是一種協(xié)助 NAT 穿透的協(xié)議。本文主要關注 STUN 協(xié)議。 ?

STUN 原理

STUN 基于一個簡單的觀察：從一個會被 NAT 的客戶端訪問公網(wǎng)服務器時，服務器看到的是 NAT 設備的公網(wǎng) ip:port 地址，而非該?客戶端的局域網(wǎng) ip:port 地址。 ? 也就是說，服務器能告訴客戶端它看到的客戶端的 ip:port 是什么。因此，只要將這個信息以某種方式告訴通信對端（peer），后者就知道該和哪個地址建連了！這樣就又簡化為前面的防火墻穿透問題了。 ? 本質(zhì)上這就是 STUN 協(xié)議的工作原理，如下圖所示： ?

筆記本向 STUN 服務器發(fā)送一個請求：“從你的角度看，我的地址什么？”

STUN 服務器返回一個響應：“我看到你的 UDP 包是從這個地址來的：ip:port”。

The STUN protocol has a bunch more stuff in it — there’s a way of obfuscating the?ip:port?in the response to stop really broken NATs from mangling the packet’s payload, and a whole authentication mechanism that only really gets used by TURN and ICE, sibling protocols to STUN that we’ll talk about in a bit. We can ignore all of that stuff for address discovery. ?

為什么 NAT 穿透邏輯和主協(xié)議要共享同一個 socket

理解了 STUN 原理，也就能理解為什么我們在文章開頭說，如果?要實現(xiàn)自己的 NAT 穿透邏輯和主協(xié)議，就必須讓二者共享同一個 socket： ?

每個 socket 在 NAT 設備上都對應一個映射關系（私網(wǎng)地址 -> 公網(wǎng)地址）；

STUN 服務器只是輔助穿透的基礎設施；

與 STUN 服務器通信之后，在 NAT 及防火墻設備上打開了一個連接，允許入向包進來（回憶前面內(nèi)容，?只要目的地址對，UDP 包就能進來，不管這些包是不是從 STUN 服務器來的）；

因此，接下來只要將這個地址告訴我們的通信對端（peer），讓它往這個地址發(fā)包，就能實現(xiàn)穿透了。

STUN 的問題：不能穿透所有 NAT 設備（例如企業(yè)級 NAT 網(wǎng)關）

有了 STUN，我們的穿透目的似乎已經(jīng)實現(xiàn)了：每臺機器都通過 STUN 來獲取自己的私網(wǎng) socket 對應的公網(wǎng) ip:port，然后把這個信息告訴對端，然后兩端同時發(fā)起穿透防火墻的嘗試，后面的過程就和上一節(jié)介紹的防火墻穿透一樣了，對嗎？ ? 答案是：看情況。某些情況下確實如此，但有些情況下卻不行。通常來說， ?

對于大部分家用路由器場景，這種方式是沒問題的；

但對于一些企業(yè)級 NAT 網(wǎng)關來說，這種方式無法奏效。

NAT 設備的說明書上越強調(diào)它的安全性，STUN 方式失敗的可能性就越高。（但注意，從實際意義上來說， NAT 設備在任何方面都并不會增強網(wǎng)絡的安全性，但這不是本文重點，因此不展開。） ?

重新審視 STUN 的前提

再次審視前面關于 STUN 的假設：當 STUN 服務器告訴客戶端在公網(wǎng)看來它的地址是?2.2.2.2:4242?時，那所有目的地址是?2.2.2.2:4242?的包就都能穿透防火墻到達該客戶端。 ? 這也正是問題所在：這一點并不總是成立。 ?

某些 NAT 設備的行為與我們假設的一致，它們的有狀態(tài)防火墻組件只要看到有客戶端自己發(fā)起的出向包，就會允許相應的入向包進入；因此只要利用 STUN 功能，再加上兩端同時發(fā)起防火墻穿透，就能把連接打通；

in theory, there are also NAT devices that are super relaxed, and don’t ship with stateful firewall stuff at all. In those, you don’t even need simultaneous transmission, the STUN request gives you an internet?ip:port?that anyone can connect to with no further ceremony. If such devices do still exist, they’re increasingly rare. ?

另外一些 NAT 設備就要困難很多了，它會針對每個目的地址來生成一條相應的映射關系。在這樣的設備上，如果我們用相同的 socket 來分別發(fā)送數(shù)據(jù)包到 5.5.5.5:1234 and 7.7.7.7:2345，我們就會得到 2.2.2.2 上的兩個不同的端口，每個目的地址對應一個。如果反向包的端口用的不對，包就無法通過防火墻。如下圖所示：

? 中場補課：NAT 正式術語

? 知道 NAT 設備的行為并不是完全一樣之后，我們來引入一些正式術語。 ?

早期術語

如果之前接觸過 NAT 穿透，可能會聽說過下面這些名詞： ?

“Full Cone”

“Restricted Cone”

“Port-Restricted Cone”

“Symmetric” NATs

這些都是 NAT 穿透領域的早期術語。 ? 但其實這些術語相當讓人困惑。我每次都要查一下 Restricted Cone NAT 是什么意思。從實際經(jīng)驗來看，我并不是唯一對此感到困惑的人。例如，如今互聯(lián)網(wǎng)上將 “easy” NAT 歸類為 Full Cone，而實際上它們更應該歸類為 Port-Restricted Cone。 ?

近期研究與新術語

最近的一些研究和 RFC 已經(jīng)提出了一些更準確的術語。 ?

首先，它們明確了如下事實：NAT 設備的行為差異表現(xiàn)在多個維度，而并非只有早期研究中所說的 “cone” 這一個維度，因此基于 “cone” 來劃分類別并不是很有幫助。

其次，新研究和新術語能更準確地描述 NAT 在做什么。

前面提到的所謂?"easy" 和 "hard" NAT，只在一個維度有不同：NAT 映射是否考慮到目的地址信息。RFC 4787 中， ?

將?easy NAT 及其變種稱為 “Endpoint-Independent Mapping” (EIM，終點無關的映射)

但是，從“命名很難”這一程序員界的偉大傳統(tǒng)來說，EIM 這個詞其實也并不是 100% 準確，因為這種 NAT 仍然依賴 endpoint，只不過依賴的是源 endpoint：每個 source ip:port 對應一個映射 —— 否則你的包就會和別人的包混在一起，導致混亂。 ? 嚴格來說，EIM 應該稱為 “Destination Endpoint Independent Mapping” (DEIM?)，但這個名字太拗口了，而且按照慣例，Endpoint 永遠指的是 Destination Endpoint。 ?

將 hard NAT 以及變種稱為 “Endpoint-Dependent Mapping”（EDM，終點相關的映射）。

EDM 中還有一個子類型，依據(jù)是只根據(jù) dst_ip 做映射，還是根據(jù) dst_ip + dst_port 做映射。對于 NAT 穿透來說，這種區(qū)分對來說是一樣的：它們都會導致 STUN 方式不可用。 ?

老的 cone 類型劃分

你可能會有疑問：根據(jù)是否依賴 endpoint 這一條件，只能組合出兩種可能，那為什么傳統(tǒng)分類中會有四種 cone 類型呢？答案是 cone 包含了兩個正交維度的 NAT 行為： ?

NAT 映射行為：前面已經(jīng)介紹過了；

有狀態(tài)防火墻行為：與前者類似，也是分為與 endpoint 相關還是無關兩種類型。

因此最終組合如下： NAT Cone Types

? 分解到這種程度之后就可以看出，cone 類型對 NAT 穿透場景來說并沒有什么意義。我們關心的只有一點：是否是 Symmetric —— 換句話說，一個 NAT 設備是 EIM 還是 EDM 類型的。 ?

針對 NAT 穿透場景：簡化 NAT 分類

以上討論可知，雖然理解防火墻的具體行為很重要，但對于編寫 NAT 穿透代碼來說，這一點并不重要。我們的兩端同時發(fā)包方式（simultaneous transmission trick）能?有效穿透以上三種類型的防火墻。在真實場景中，我們主要在處理的是 IP-and-port endpoint-dependent 防火墻。 ? 因此，對于實際 NAT 穿透實現(xiàn)，我們可以將以上分類簡化成：

更多 NAT 規(guī)范（RFC）

想了解更多新的 NAT 術語，可參考 ?

RFC?4787?(NAT Behavioral Requirements for UDP)

RFC?5382?(for TCP)

RFC?5508?(for ICMP)

如果自己實現(xiàn) NAT，那應該遵循這些 RFC 的規(guī)范，這樣才能使你的 NAT 行為符合業(yè)界慣例，與其他廠商的設備或軟件良好兼容。 ?

穿透 NAT+防火墻：STUN 不可用時，fallback 到中繼模式

問題回顧與保底方式（中繼）

補完基礎知識（尤其是定義了什么是 hard NAT）之后，回到我們的 NAT 穿透主題。 ?

第 1~4 節(jié)已經(jīng)解決了 STUN 和防火墻穿透的問題；

但 hard NAT 對我們來說是個大問題，只要路徑上出現(xiàn)一個這種設備，前面的方案就行不通了。

準備放棄了嗎？這才進入 NAT 真正有挑戰(zhàn)的部分：如果已經(jīng)試過了前面介紹的所有方式仍然不能穿透，我們該怎么辦呢？ ?

實際上，確實有很多 NAT 實現(xiàn)在這種情況下都會選擇放棄，向用戶報一個“無法連接”之類的錯誤。

但對我們來說，這么快就放棄顯然是不可接受的 —— 解決不了連通性問題，Tailscale 就沒有存在的意義。

我們的保底解決方式是：創(chuàng)建一個中繼連接（relay）實現(xiàn)雙方的無障礙地通信。但是，中繼方式性能不是很差嗎？這要看具體情況： ?

如果能直連，那顯然沒必要用中繼方式；

但如果無法直連，而中繼路徑又非常接近雙方直連的真實路徑，并且?guī)捵銐虼?，那?繼方式并不會明顯降低通信質(zhì)量。延遲肯定會增加一點，帶寬會占用一些，但?相比完全連接不上，還是更能讓用戶接受的。

不過要注意：我們只有在無法直連時才會選擇中繼方式。實際場景中， ?

對于大部分網(wǎng)絡，我們都能通過前面介紹的方式實現(xiàn)直連；

剩下的長尾用中繼方式來解決，并不算一個很糟的方式。

此外，某些網(wǎng)絡會阻止 NAT 穿透，其影響比這種 hard NAT 大多了。例如，我們觀察到 UC Berkeley guest WiFi 禁止除 DNS 流量之外的所有 outbound UDP 流量。不管用什么 NAT 黑科技，都無法繞過這個攔截。因此我們終歸還是需要一些可靠的 fallback 機制。 ?

中繼協(xié)議：TURN、DERP

有多種中繼實現(xiàn)方式。 ? 1）TURN (Traversal Using Relays around NAT)：經(jīng)典方式，核心理念是 ?

用戶（人）先去公網(wǎng)上的 TURN 服務器認證，成功后后者會告訴你：“我已經(jīng)為你分配了 ip:port，接下來將為你中繼流量”；

然后將這個 ip:port 地址告訴對方，讓它去連接這個地址，接下去就是非常簡單的客戶端/服務器通信模型了。

Tailscale 并不使用 TURN。這種協(xié)議用起來并不是很好，而且與 STUN 不同，它沒有真正的交互性，因為互聯(lián)網(wǎng)上并沒有公開的 TURN 服務器。 ? 2）DERP (Detoured Encrypted Routing Protocol) ? 這是我們創(chuàng)建的一個協(xié)議，DERP。 ?

它是一個通用目的包中繼協(xié)議，運行在 HTTP 之上，而大部分網(wǎng)絡都是允許 HTTP 通信的。

它根據(jù)目的公鑰（destination’s public key）來中繼加密的流量（encrypted payloads）。

前面也簡單提到過，DERP 既是我們在 NAT 穿透失敗時的保底通信方式（此時的角色與 TURN 類似），也是在其他一些場景下幫助我們完成 NAT 穿透的旁路信道。換句話說，它既是我們的保底方式，也是有更好的穿透鏈路時，幫助我們進行連接升級（upgrade to a peer-to-peer connection）的基礎設施。 ?

小結(jié)

有了“中繼”這種保底方式之后，我們穿透的成功率大大增加了。如果此時不再閱讀本文接下來的內(nèi)容，而是把上面介紹的穿透方式都實現(xiàn)了，我預計： ?

90% 的情況下，你都能實現(xiàn)直連穿透；

剩下的 10% 里，用中繼方式能穿透一些（some）；

這已經(jīng)算是一個“足夠好”的穿透實現(xiàn)了。 ?

穿透 NAT+防火墻：企業(yè)級改進

如果你并不滿足于“足夠好”，那我們可以做的事情還有很多！ ? 本節(jié)將介紹一些五花八門的 tricks，在某些特殊場景下會幫到我們。單獨使用這項技術都無法解決 NAT 穿透問題，但將它們巧妙地組合起來，我們能更加接近 100% 的穿透成功率。 ?

穿透 hard NAT：暴力端口掃描

回憶 hard NAT 中遇到的問題，如下圖所示，關鍵問題是：easy NAT 不知道該往 hard NAT 方的哪個 ip:port 發(fā)包。

但必須要往正確的 ip:port 發(fā)包，才能穿透防火墻，實現(xiàn)雙向互通。怎么辦呢？ ?

首先，我們能知道 hard NAT 的一些 ip:port，因為我們有 STUN 服務器。

這里先假設我們獲得的這些 IP 地址都是正確的（這一點并不總是成立，但這里先這么假設。而實際上，大部分情況下這一點都是成立的，如果對此有興趣，可以參考 REQ-2 in RFC 4787）。

IP 地址確定了，剩下的就是端口了?？偣灿?65535 中可能，我們能遍歷這個端口范圍嗎？

如果發(fā)包速度是 100 packets/s，那最壞情況下，需要 10 分鐘來找到正確的端口。還是那句話，這雖然不是最優(yōu)的，但總比連不上好。 ? 這很像是端口掃描（事實上，確實是），實際中可能會觸發(fā)對方的網(wǎng)絡入侵檢測軟件。 ?

基于生日悖論改進暴力掃描：hard side 多開端口 + easy side 隨機探測

利用 birthday paradox 算法，我們能對端口掃描進行改進。 ?

上一節(jié)的基本前提是：hard side 只打開一個端口，然后 easy side 暴力掃描 65535 個端口來尋找這個端口；

這里的改進是：在 hard size 開多個端口，例如 256 個（即同時打開 256 個 socket，目的地址都是 easy side 的 ip:port），然后 easy side 隨機探測這邊的端口。

這里省去算法的數(shù)學模型，如果你對實現(xiàn)干興趣，可以看看我寫的 python calculator。計算過程是“經(jīng)典”生日悖論的一個小變種。下面是隨著 easy side random probe 次數(shù)（假設 hard size 256 個端口）的變化，兩邊打開的端口有重合（即通信成功）的概率：

? 根據(jù)以上結(jié)果，如果還是假設 100 ports/s 這樣相當溫和的探測速率，那 2 秒鐘就有約 50% 的成功概率。即使非常不走運，我們?nèi)匀荒茉?20s 時幾乎 100% 穿透成功，而此時只探測了總端口空間的 4%。 ? 非常好！雖然這種 hard NAT 給我們帶來了嚴重的穿透延遲，但最終結(jié)果仍然是成功的。那么，如果是兩個 hard NAT，我們還能處理嗎？ ?

雙 hard NAT 場景

這種情況下仍然可以用前面的?多端口+隨機探測?方式，但成功概率要低很多了： ?

每次通過一臺 hard NAT 去探測對方的端口（目的端口）時，我們自己同時也生成了一個隨機源端口；

這意味著我們的搜索空間變成了二維?{src port, dst port}?對，而不再是之前的一維 dst port 空間。

這里我們也不就具體計算展開，只告訴結(jié)果：仍然假設目的端打開 256 個端口，從源端發(fā)起 2048 次（20 秒），成功的概率是：0.01%。 ? 如果你之前學過生日悖論，就并不會對這個結(jié)果感到驚訝。理論上來說， ?

要達到 99.9% 的成功率，我們需要兩邊各進行170,000 次探測 —— 如果還是以 100 packets/sec 的速度，就需要 28 分鐘。

要達到 50% 的成功率，“只”需要 54,000 packets，也就是 9 分鐘。

如果不使用生日悖論方式，而且暴力窮舉，需要 1.2 年時間！

對于某些應用來說，28 分鐘可能仍然是一個可接受的時間。用半個小時暴力穿透 NAT 之后，這個連接就可以一直用著 —— 除非 NAT 設備重啟，那樣就需要再次花半個小時穿透建個新連接。但對于交互式應用來說，這樣顯然是不可接受的。 ? 更糟糕的是，如果去看常見的辦公網(wǎng)路由器，你會震驚于它的 active session low limit 有多么低。例如，一臺 Juniper SRX 300?最多支持 64,000 active sessions。也就是說， ?

如果我們想創(chuàng)建一個成功的穿透連接，就會把它的整張 session 表打爆?（因為我們要暴力探測 65535 個端口，每次探測都是一條新連接記錄）！這顯然要求這臺路由器能從容優(yōu)雅地處理過載的情況。

這只是創(chuàng)建一條連接帶來的影響！如果 20 臺機器同時對這臺路由器發(fā)起穿透呢？絕對的災難！

至此，我們通過這種方式穿透了比之前更難一些的網(wǎng)絡拓撲。這是一個很大的成就，因為?家用路由器一般都是 easy NAT，hard NAT 一般都是辦公網(wǎng)路由器或云 NAT 網(wǎng)關。 ?

home-to-office（家->辦公室）

home-to-cloud （家->云）

這意味著這種方式能幫我們解決上述的場景，以及一部分以下場景。 ?

office-to-cloud （辦公室->云）

cloud-to-cloud （云->辦公室）

控制端口映射（port mapping）過程：UPnP/NAT-PMP/PCP 協(xié)議

如果我們能讓 NAT 設備的行為簡單點，不要把事情搞這么復雜，那建立連接（穿透）就會簡單很多。真有這樣的好事嗎？還真有，有專門的一種協(xié)議叫?端口映射協(xié)議（port mapping protocols）。通過這種協(xié)議禁用掉前面遇到的那些亂七八糟的東西之后，我們將得到一個非常簡單的“請求-響應”。 ? 下面是三個具體的端口映射協(xié)議： ?

UPnP IGD?(Universal Plug’n’Play Internet Gateway Device)

最老的端口控制協(xié)議，誕生于 1990s 晚期，因此使用了很多上世紀 90 年代的技術（XML、SOAP、multicast HTTP over UDP —— 對，HTTP over UDP ），而且很難準確和安全地實現(xiàn)這個協(xié)議。但以前很多路由器都內(nèi)置了 UPnP 協(xié)議，現(xiàn)在仍然很多。請求和響應： ? “你好，請將我的?lan-ip:port?轉(zhuǎn)發(fā)到公網(wǎng)（WAN）”， “好的，我已經(jīng)為你分配了一個公網(wǎng)映射 wan-ip:port ”。 ?

NAT-PMP

UPnP IGD 出來幾年之后，Apple 推出了一個功能類似的協(xié)議，名為 NAT-PMP (NAT Port Mapping Protocol)。 ? 但與 UPnP 不同，這個協(xié)議只做端口轉(zhuǎn)發(fā)，不管是在客戶端還是服務端，實現(xiàn)起來都非常簡單。 ?

PCP

稍后一點，又出現(xiàn)了 NAT-PMP v2 版，并起了個新名字PCP (Port Control Protocol)。 ? 因此要更好地實現(xiàn)穿透，可以 ?

先判斷本地的默認網(wǎng)關上是否啟用了 UPnP IGD, NAT-PMP and PCP；

如果探測發(fā)現(xiàn)其中任何一種協(xié)議有響應，我們就申請一個公網(wǎng)端口映射；

可以將這理解為一個加強版 STUN：我們不僅能發(fā)現(xiàn)自己的公網(wǎng) ip:port，而且能指示我們的 NAT 設備對我們的通信對端友好一些 —— 但并不是為這個端口修改或添加防火墻規(guī)則。

但我們不能假設這個協(xié)議一定可用： ?

本地 NAT 設備可能不支持這個協(xié)議；

設備支持但默認禁用了，或者沒人知道還有這么個功能，因此從來沒開過；

安全策略要求關閉這個特性。

這一點非常常見，因為 UPnP 協(xié)議曾曝出一些高危漏洞（后面都修復了，因此如果是較新的設備，可以安全地使用 UPnP —— 如果實現(xiàn)沒問題）。不幸的是，某些設備的配置中，UPnP, NAT-PMP，PCP 是放在一個開關里的（可能統(tǒng)稱為 “UPnP” 功能），一開全開，一關全關。因此如果有人擔心 UPnP 的安全性，他連另外兩個也用不了。 ? 最后，終歸來說，只要這種協(xié)議可用，就能有效地減少一次 NAT，大大方便建連過程。但接下來看一些不常見的場景。 ?

多 NAT 協(xié)商（Negotiating numerous NATs）

目前為止，我們看到的客戶端和服務端都各只有一個 NAT 設備。如果有多個 NAT 設備會怎么樣？例如下面這種拓撲： ?

這個例子比較簡單，不會給穿透帶來太大問題。包從客戶端 A 經(jīng)過多次 NAT 到達公網(wǎng)的過程，與前面分析的穿過多層有狀態(tài)防火墻是一樣的： ?

額外的這層（NAT 設備）對客戶端和服務端來說都不可見，我們的穿透技術也不關心中間到底經(jīng)過了多少層設備。

真正有影響的其實只是最后一層設備，因為對端需要在這一層設備上找到入口讓包進來。

具體來說，真正有影響的是端口轉(zhuǎn)發(fā)協(xié)議。 ?

客戶端使用這種協(xié)議分配端口時，為我們分配端口的是最靠近客戶端的這層 NAT 設備；

而我們期望的是讓最離客戶端最遠的那層 NAT 來分配，否則我們得到的就是一個網(wǎng)絡中間層分配的 ip:port，對端是用不了的；

不幸的是，這幾種協(xié)議都不能遞歸地告訴我們下一層 NAT 設備是多少 —— 雖然可以用 traceroute 之類的工具來探測網(wǎng)絡路徑，再加上猜路上的設備是不是 NAT 設備（嘗試發(fā)送 NAT 請求） —— 但這個就看運氣了。

這就是為什么互聯(lián)網(wǎng)上充斥著大量的文章說 double-NAT 有多糟糕，以及警告用戶為保持后向兼容不要使用 double-NAT。但實際上，double-NAT 對于絕大部分互聯(lián)網(wǎng)應用來說都是不可見的（透明的），因為大部分應用并不需要主動地做這種 NAT 穿透。 ? 但我也絕不是在建議你在自己的網(wǎng)絡中設置 double-NAT。 ?

破壞了端口映射協(xié)議之后，某些視頻游戲的多人（multiplayer）模式就會無法使用；

也可能會使你的 IPv6 網(wǎng)絡無法派上用場，后者是不用 NAT 就能雙向直連的一個好方案。

但如果 double-NAT 并不是你能控制的，那除了不能用到這種端口映射協(xié)議之外，其他大部分東西都是不受影響的。 ? double-NAT 的故事到這里就結(jié)束了嗎？—— 并沒有，而且更大型的 double-NAT 場景將展現(xiàn)在我們面前。 ?

運營商級 NAT 帶來的問題

即使用 NAT 來解決 IPv4 地址不夠的問題，地址仍然是不夠用的，ISP（互聯(lián)網(wǎng)服務提供商）顯然無法為每個家庭都分配一個公網(wǎng) IP 地址。那怎么解決這個問題呢？ISP 的做法是不夠了就再嵌套一層 NAT： ?

家用路由器將你的客戶端 SNAT 到一個 “intermediate” IP 然后發(fā)送到運營商網(wǎng)絡；

ISP’s network 中的 NAT 設備再將這些 intermediate IPs 映射到少量的公網(wǎng) IP。

后面這種 NAT 就稱為“運營商級 NAT”（carrier-grade NAT，或稱電信級 NAT），縮寫 CGNAT。如下圖所示：

CGNAT 對 NAT 穿透來說是一個大麻煩。 ?

在此之前，辦公網(wǎng)用戶要快速實現(xiàn) NAT 穿透，只需在他們的路由器上手動設置端口映射就行了。

但有了 CGNAT 之后就不管用了，因為你無法控制運營商的 CGNAT！

好消息是：這其實是 double-NAT 的一個小變種，因此前面介紹的解決方式大部分還仍然是適用的。某些東西可能會無法按預期工作，但只要肯給 ISP 交錢，這些也都能解決。除了 port mapping protocols，其他我們已經(jīng)介紹的所有東西在 CGNAT 里都是適用的。 ? 新挑戰(zhàn)：同一 CGNAT 側(cè)直連，STUN 不可用 ? 但我們確實遇到了一個新挑戰(zhàn)：如何直連兩個在同一 CGNAT 但不同家用路由器中的對端呢？如下圖所示：

在這種情況下，STUN 就無法正常工作了：STUN 看到的是客戶端在公網(wǎng)（CGNAT 后面）看到的地址，而我們想獲得的是在 “middle network” 中的 ip:port，這才是對端真正需要的地址， ?

解決方案：如果端口映射協(xié)議能用：一端做端口映射 ? 怎么辦呢？

如果你想到了端口映射協(xié)議，那恭喜，答對了！如果 peer 中任何一個 NAT 支持端口映射協(xié)議，對我們就能實現(xiàn)穿透，因為它分配的 ip:port 正是對端所需要的信息。 ? 這里諷刺的是：double-NAT（指 CGNAT）破壞了端口映射協(xié)議，但在這里又救了我們！當然，我們假設這些協(xié)議一定可用，因為 CGNAT ISP 傾向于在它們的家用路由器側(cè)關閉這些功能，已避免軟件得到“錯誤的”結(jié)果，產(chǎn)生混淆。 ?

解決方案：如果端口映射協(xié)議不能用：NAT hairpin 模式

如果不走運，NAT 上沒有端口映射功能怎么辦？ ? 讓我們回到基于 STUN 的技術，看會發(fā)生什么。兩端在 CGNAT 的同一側(cè)，假設 STUN 告訴我們 A 的地址是 2.2.2.2:1234，B 的地址是?2.2.2.2:5678。 ? 那么接下來的問題是：如果 A 向?2.2.2.2:5678?發(fā)包會怎么樣？期望的 CGNAT 行為是： ? 執(zhí)行 A 的 NAT 映射規(guī)則，即對?2.2.2.2:1234 -> 2.2.2.2:5678?進行 SNAT。 ? 注意到目的地址?2.2.2.2:5678?匹配到的是 B 的入向 NAT 映射，因此接著對這個包執(zhí)行 DNAT，將目的 IP 改成 B 的私有地址。 ? 通過 CGNAT 的 internal 接口（而不是 public 接口，對應公網(wǎng)）將包發(fā)給 B。 ? 這種 NAT 行為有個專門的術語，叫?hairpinning（直譯為發(fā)卡，意思是像發(fā)卡一樣，沿著一邊上去，然后從另一邊繞回來），
大家應該猜到的一個事實是：不是所以 NAT 都支持 hairpin 模式。實際上，大量 well-behaved NAT 設備都不支持 hairpin 模式， ?

因為它們都有?“只有 src_ip 是私有地址且 dst_ip 是公網(wǎng)地址的包才會經(jīng)過我”?之類的假設。

因此對于這種目的地址不是公網(wǎng)、需要讓路由器把包再轉(zhuǎn)回內(nèi)網(wǎng)的包，它們會直接丟棄。

這些邏輯甚至是直接實現(xiàn)在路由芯片中的，因此除非升級硬件，否則單靠軟件編程無法改變這種行為。

Hairpin 是所有 NAT 設備的特性（支持或不支持），并不是 CGNAT 獨有的。 ?

在大部分情況下，這個特性對我們的 NAT 穿透目的來說都是無所謂的，因為我們期望中?兩個 LAN NAT 設備會直接通信，不會再向上繞到它們的默認網(wǎng)關 CGNAT 來解決這個問題。

Hairpin 特性可有可無這件事有點遺憾，這可能也是為什么 hairpin 功能經(jīng)常 broken 的原因。 ?

一旦必須涉及到 CGNAT，那 hairpinning 對連接性來說就至關重要了。

Hairpinning 使內(nèi)網(wǎng)連接的行為與公網(wǎng)連接的行為完成一致，因此我們無需關心目的地址類型，也不用知曉自己是否在一臺 CGNAT 后面。 ? 如果 hairpinning 和 port mapping protocols 都不可用，那只能降級到中繼模式了。 ?

全 IPv6 網(wǎng)絡：理想之地，但并非問題全無

行文至此，一些讀者可能已經(jīng)對著屏幕咆哮：不要再用 IPv4 了！?花這么多時間精力解決這些沒意義的東西，還不如直接換成 IPv6！ ?

的確，之所以有這些亂七八糟的東西，就是因為 IPv4 地址不夠了，我們一直在用越來越復雜的 NAT 來給 IPv4 續(xù)命。

如果 IP 地址夠用，無需 NAT 就能讓世界上的每個設備都有一個自己的公網(wǎng) IP 地址，這些問題不就解決了嗎？

簡單來說，是的，這也正是 IPv6 能做的事情。但是，也只說對了一半：在理想的全 IPv6 世界中，所有這些東西會變得更加簡單，但我們面臨的問題并不會完全消失?—— 因為有狀態(tài)防火墻仍然還是存在的。 ?

辦公室中的電腦可能有一個公網(wǎng) IPv6 地址，但你們公司肯定會架設一個防火墻，只允許你的電腦主動訪問公網(wǎng)，而不允許反向主動建連。

其他設備上的防火墻也仍然存在，應用類似的規(guī)則。

因此，我們?nèi)匀粫玫??

本文最開始介紹的防火墻穿透技術，以及；

幫助我們獲取自己的公網(wǎng) ip:port 信息的旁路信道；

仍然需要在某些場景下 fallback 到中繼模式，例如 fallback 到最通用的 HTTP 中繼協(xié)議，以繞過某些網(wǎng)絡禁止 outbound UDP 的問題。

但我們現(xiàn)在可以拋棄 STUN、生日悖論、端口映射協(xié)議、hairpin 等等東西了。這是一個好消息！ ?

全球 IPv4/IPv6 部署現(xiàn)狀

另一個更加嚴峻的現(xiàn)實問題是：當前并不是一個全 IPv6 世界。目前世界上 ?

大部分還是 IPv4；

大約 33% 是 IPv6，而且分布極度不均勻，因此某些通信對所在的可能是 100% IPv6，也可能是 0%，或二者之間。

不幸的是，這意味著，IPv6 **還**無法作為我們的解決方案。就目前來說，它只是我們的工具箱中的一個備選。對于某些 peer 來說，它簡直是完美工具，但對其他 peer 來說，它是用不了的。如果目標是“任何情況下都能穿透（連接）成功”，那我們就仍然需要 IPv4+NAT 那些東西。 ?

新場景：NAT64/DNS64

IPv4/IPv6 共存也引出了一個新的場景：NAT64 設備。

前面介紹的都是 NAT44 設備：它們將一個 IPv4 地址轉(zhuǎn)換成另一 IPv4 地址。NAT64 從名字可以看出，是將一個內(nèi)側(cè) IPv6 地址轉(zhuǎn)換成一個外側(cè) IPv4 地址。利用 DNS64 設備，我們能將 IPv4 DNS 應答給 IPv6 網(wǎng)絡，這樣對終端來說，它看到的就是一個全 IPv6 網(wǎng)絡，而仍然能訪問 IPv4 公網(wǎng)。 ? Incidentally, you can extend this naming scheme indefinitely. There have been some experiments with NAT46; you could deploy NAT66 if you enjoy chaos; and some RFCs use NAT444 for carrier-grade NAT. ? 如果需要處理 DNS 問題，那這種方式工作良好。例如，如果連接到 google.com，將這個域名解析成 IP 地址的過程會涉及到 DNS64 設備，它又會進一步 involve NAT64 設備，但后一步對用戶來說是無感知的。 ? 但對于 NAT 和防火墻穿透來說，我們會關心每個具體的 IP 地址和端口。 ? 解決方案：CLAT (Customer-side transLATor) ? 如果設備支持 CLAT (Customer-side translator — from Customer XLAT)，那我們就很幸運： ?

CLAT 假裝操作系統(tǒng)有直接 IPv4 連接，而背后使用的是 NAT64，以對應用程序無感知。在有 CLAT 的設備上，我們無需做任何特殊的事情。

CLAT 在移動設備上非常常見，但在桌面電腦、筆記本和服務器上非常少見，因此在后者上，必須自己做 CLAT 做的事情：檢測 NAT64+DNS64 的存在，然后正確地使用它們。

解決方案：CLAT 不存在時，手動穿透 NAT64 設備

首先檢測是否存在 NAT64+DNS64。

方法很簡單：向 ipv4only.arpa. 發(fā)送一個 DNS 請求。這個域名會解析到一個已知的、固定的 IPv4 地址，而且是純 IPv4 地址。如果得到的是一個 IPv6 地址，就可以判斷有 DNS64 服務器做了轉(zhuǎn)換，而它必然會用到 NAT64。這樣就能判斷出 NAT64 的前綴是多少。 ?

此后，要向 IPv4 地址發(fā)包時，發(fā)送格式為{NAT64 prefix + IPv4 address}?的 IPv6 包。類似地，收到來源格式為?{NAT64 prefix + IPv4 address}?的包時，就是 IPv4 流量。

接下來，通過 NAT64 網(wǎng)絡與 STUN 通信來獲取自己在 NAT64 上的公網(wǎng) ip:port，接下來就回到經(jīng)典的 NAT 穿透問題了 —— 除了需要多做一點點事情。

幸運的是，如今的大部分 v6-only 網(wǎng)絡都是移動運營商網(wǎng)絡，而幾乎所有手機都支持 CLAT。運營 v6-only 網(wǎng)絡的 ISPs 會在他們給你的路由器上部署 CLAT，因此最后你其實不需要做什么事情。但如果想實現(xiàn) 100% 穿透，就需要解決這種邊邊角角的問題，即必須顯式支持從 v6-only 網(wǎng)絡連接 v4-only 對端。 ?

將所有解決方式集成到 ICE 協(xié)議

針對具體場景，該選擇哪種穿透方式？ ? 至此，我們的 NAT 穿透之旅終于快結(jié)束了。我們已經(jīng)覆蓋了有狀態(tài)防火墻、簡單和高級 NAT、IPv4 和 IPv6。只要將以上解決方式都實現(xiàn)了，NAT 穿透的目的就達到了！ ? 但是： ?

對于給定的 peer，如何判斷改用哪種方式呢？

如何判斷這是一個簡單有狀態(tài)防火墻的場景，還是該用到生日悖論算法，還是需要手動處理 NAT64 呢？

還是通信雙方在一個 WiFi 網(wǎng)絡下，連防火墻都沒有，因此不需要任何操作呢？

早期 NAT 穿透比較簡單，能讓我們精確判斷出 peer 之間的路徑特點，然后針對性地采用相應的解決方式。但后面，網(wǎng)絡工程師和 NAT 設備開發(fā)工程師引入了一些新理念，給路徑判斷造成很大困難。因此我們需要簡化客戶端側(cè)的思考（判斷邏輯）。 ? 這就要提到 Interactive Connectivity Establishment (ICE，交換式連接建立) 協(xié)議了。與 STUN/TURN 類似，ICE 來自電信領域，因此其 RFC 充滿了 SIP、SDP、信令會話、撥號等等電話術語。但如果忽略這些領域術語，我們會看到它描述了一個極其優(yōu)雅的判斷最佳連接路徑的算法。 ? 真的？這個算法是：每種方法都試一遍，然后選擇最佳的那個方法。就是這個算法，驚喜嗎？ ? 來更深入地看一下這個算法。 ? ICE (Interactive Connectivity Establishment) 算法 ? 這里的討論不會嚴格遵循 ICE spec，因此如果是在自己實現(xiàn)一個可互操作的 ICE 客戶端，應該通讀RFC 8445, 根據(jù)它的描述來實現(xiàn)。這里忽略所有電信術語，只關注核心的算法邏輯，并提供幾個在 ICE 規(guī)范允許范圍的靈活建議。 ? 1）為實現(xiàn)和某個 peer 的通信，首先需要確定我們自己用的（客戶端側(cè)）這個 socket 的地址，這是一個列表，至少應該包括： ?

我們自己的 IPv6?ip:ports

我們自己的 IPv4 LAN?ip:ports（局域網(wǎng)地址）

通過 STUN 服務器獲取到的我們自己的 IPv4 WAN?ip:ports（公網(wǎng)地址，可能會經(jīng)過 NAT64 轉(zhuǎn)換）

通過端口映射協(xié)議獲取到的我們自己的 IPv4 WAN?ip:port（NAT 設備的端口映射協(xié)議分配的公網(wǎng)地址）

運營商提供給我們的 endpoints（例如，靜態(tài)配置的端口轉(zhuǎn)發(fā)）

2）通過旁路信道與 peer 互換這個列表。兩邊都拿到對方的列表后，就開始互相探測對方提供的地址。?列表中地址沒有優(yōu)先級，也就是說，如果對方給的了 15 個地址，那我們應該把這 15 個地址都探測一遍。 ? 這些探測包有兩個目的： ?

打開防火墻，穿透 NAT，也就是本文一直在介紹的內(nèi)容；

健康檢測。我們在不斷交換（最好是已認證的）“ping/pong” 包，來檢測某個特定的路徑是不是端到端通的。

3）最后，一小會兒之后，從可用的備選地址中（根據(jù)某些條件）選擇“最佳”的那個，任務完成！ ? 這個算法的優(yōu)美之處在于：只要選擇最佳線路（地址）的算法是正確的，那就總能獲得最佳路徑。 ?

ICE 會預先對這些備選地址進行排序（通常：LAN > WAN > WAN+NAT），但用戶也可以自己指定這個排序行為。

從 v0.100.0 開始，Tailscale 從原來的 hardcode 優(yōu)先級切換成了根據(jù) round-trip latency 的方式，它大部分情況下排序的結(jié)果和 LAN > WAN > WAN+NAT 是一致的。但相比于靜態(tài)排序，我們是動態(tài)計算每條路徑應該屬于哪個類別。

ICE spec 將協(xié)議組織為兩個階段： ?

探測階段

通信階段

但不一定要嚴格遵循這兩個步驟的順序。在 Tailscale， ?

我們發(fā)現(xiàn)更優(yōu)的路徑之后就會自動切換過去；

所有的連接都是先選擇 DERP 模式（中繼模式）。這意味著連接立即就能建立（優(yōu)先級最低但 100% 能成功的模式），用戶不用任何等待；

然后并行進行路徑發(fā)現(xiàn)。通常幾秒鐘之后，我們就能發(fā)現(xiàn)一條更優(yōu)路徑，然后將現(xiàn)有連接透明升級（upgrade）過去。

但有一點需要關心：非對稱路徑。ICE 花了一些精力來保證通信雙方選擇的是相同的網(wǎng)絡路徑，這樣才能保證這條路徑上有雙向流量，能保持防火墻和 NAT 設備的連接一直處于 open 狀態(tài)。自己實現(xiàn)的話，其實并不需要花同樣大的精力來實現(xiàn)這個保證，但需要確保你所有使用的所有路徑上，都有雙向流量。這個目標就很簡單了，只需要定期在所有已使用的路徑上發(fā) ping/pong 就行了。 ? 健壯性與降級 ? 要實現(xiàn)健壯性，還需要檢測當前已選擇的路徑是否已經(jīng)失敗了（例如，NAT 設備維護清掉了所有狀態(tài)），如果失敗了就要降級（downgrade）到其他路徑。這里有兩種方式： ?

持續(xù)探測所有路徑，維護一個降級時會用的備用地址列表；

直接降級到保底的中繼模式，然后再通過路徑探測升級到更好的路徑。

考慮到發(fā)生降級的概率是非常小的，因此這種方式可能是更經(jīng)濟的。

安全

最后需要提到安全。 ? 本文的所有內(nèi)容都假設：我們使用的上層協(xié)議已經(jīng)有了自己的安全機制（例如 QUIC 協(xié)議有 TLS 證書，WireGuard 協(xié)議有自己的公鑰）。如果還沒有安全機制，那顯然是要立即補上的。一旦動態(tài)切換路徑，基于 IP 的安全機制就是無用的了?（IP 協(xié)議最開始就沒怎么考慮安全性），至少要有端到端的認證。

嚴格來說，如果上層協(xié)議有安全機制，那即使收到是欺騙性的 ping/pong 流量，問題都不大，最壞的情況也就是攻擊者誘導兩端通過他們的系統(tǒng)來中繼流量。而有了端到端安全機制，這并不是一個大問題（取決于你的威脅模型）。

但出于謹慎考慮，最好還是對路徑發(fā)現(xiàn)的包也做認證和加密。具體如何做可以咨詢你們的應用安全工程師。

結(jié)束語

我們終于完成了 NAT 穿透的目標！ ? 如果實現(xiàn)了以上提到的所有技術，你將得到一個業(yè)內(nèi)領先的 NAT 穿透軟件，能在絕大多數(shù)場景下實現(xiàn)端到端直連。如果直連不了，還可以降級到保底的中繼模式（對于長尾來說只能靠中繼了）。 ? 但這些工作相當復雜！其中一些問題研究起來很有意思，但很難做到完全正確，尤其是那些非常邊邊角角的場景，真正出現(xiàn)的概率極小，但解決它們所需花費的經(jīng)歷又極大。不過，這種工作只需要做一次，一旦解決了，你就具備了某種超級能力：探索令人激動的、相對還比較嶄新的端到端應用（peer-to-peer applications）世界。 ?

跨公網(wǎng) 端到端直連

去中心化軟件領域中的許多有趣想法，簡化之后其實都變成了?跨過公網(wǎng)（互聯(lián)網(wǎng)）實現(xiàn)端到端直連?這一問題，開始時可能覺得很簡單，但真正做才發(fā)現(xiàn)比想象中難多了?，F(xiàn)在知道如何解決這個問題了，動手開做吧！ ?

結(jié)束語之 TL; DR

實現(xiàn)健壯的 NAT 穿透需要下列基礎： ?

一種基于 UDP 的協(xié)議；

能在程序內(nèi)直接訪問 socket；

有一個與 peer 通信的旁路信道；

若干 STUN 服務器；

一個保底用的中繼網(wǎng)絡（可選，但強烈推薦）。

然后需要： ?

遍歷所有的 ip:port；

查詢 STUN 服務器來獲取自己的公網(wǎng) ip:port 信息，以及判斷自己這一側(cè)的 NAT 的“難度”（difficulty）；