How NAT traversal works

Learn how NAT traversal works, how Tailscale can get through and securely connect your devices directly to each other.

网络地址转换（NAT）穿透技术与 P2P 连接架构深度研究报告

1. 引言：互联网连接性的演变与挑战

互联网架构的原始愿景是建立一个端到端（End-to-End）的通信网络，任何接入网络的节点都应当能够直接向任何其他节点发送数据包。然而，随着互联网的爆发式增长，IPv4 地址枯竭危机迫使网络架构发生了根本性的异化。为了应对这一危机，网络地址转换（NAT）设备与有状态防火墙（Stateful Firewalls）被大规模部署。这些中间设备虽然有效延缓了地址耗尽问题并提供了基础的安全屏障，但同时也破坏了互联网的连通性假设，在设备之间竖立了无数道隐形的通信壁垒。

本报告将基于 Tailscale 的技术文档《How NAT Traversal Works》，对现代网络中的 NAT 穿透技术进行详尽的、专家级的深度剖析。报告将系统性地拆解从基础防火墙原理到复杂的 NAT 行为模式，深入探讨 STUN、TURN、ICE 等标准协议的运作机制，并重点分析“打洞”（Hole Punching）技术在不同网络环境下的实现细节。特别是在面对“困难 NAT”（Hard NAT）时，如何利用生日悖论（Birthday Paradox）进行概率性穿透，以及在穿透失败时如何构建高效的中继网络（DERP），将是本报告的核心研究内容。通过对这些技术的全景式解读，旨在揭示现代 P2P 网络如何在充满阻碍的现实网络环境中，重建“直接连接”的通信能力。

2. 防火墙（Firewalls）：状态监测与流量控制的基石

在深入探讨 NAT 之前，必须首先理解现代防火墙的工作机制，因为 NAT 设备通常也兼具防火墙的功能。防火墙是网络安全的第一道防线，其核心逻辑决定了流量是否能够进入内网。

2.1 有状态防火墙（Stateful Firewalls）的运作机理

早期的防火墙通常是无状态的包过滤器，仅依据静态规则（如允许特定端口）来决定数据包的去留。然而，现代绝大多数防火墙，包括家用路由器和企业级网关，都是“有状态”的（Stateful）。

有状态防火墙并不只是简单地检查数据包的头部信息，它维护着一张动态的“状态表”（State Table）。这张表记录了当前活跃的所有网络连接的上下文信息。其核心逻辑可以概括为：默认拒绝所有入站连接，允许所有出站连接。

当内网的一台主机（Client A）试图向外网发送数据时，防火墙会执行以下操作：

1. 出站放行：防火墙允许该数据包通过。
2. 状态记录：防火墙在内部内存中创建一个状态条目，记录该连接的“五元组”信息（源IP、源端口、目的IP、目的端口、协议）。这个条目意味着：“我刚刚看到内网的主机 A 向外网的主机 B 发起了对话。”
3. 入站匹配：当外网有数据包试图进入内网时，防火墙会查阅状态表。只有当入站数据包的特征（通常是反向的五元组）与状态表中已存在的条目相匹配时，该数据包才会被允许通过 ¹。

这种机制确保了内网主机可以主动访问互联网，但互联网上的恶意扫描无法主动触达内网主机。然而，对于点对点（P2P）通信而言，这构成了巨大的障碍：如果双方都位于防火墙之后，谁也无法先迈出第一步。

2.2 UDP 协议的特殊性与超时机制

在 TCP 协议中，连接的建立（SYN/ACK）和终止（FIN/RST）有明确的状态标志，防火墙可以据此精准地创建和销毁状态条目。然而，UDP 是无连接协议，数据包之间没有序列号或连接标志。为了支持 UDP 通信（如 DNS 查询、视频流、VPN 隧道），有状态防火墙必须采用一种启发式的状态维护机制。

防火墙遵循“UDP 规则”：当看到一个出站的 UDP 包时，它假定这是一个新会话的开始，并为此创建一个临时的状态条目。由于没有“断开连接”的信号，防火墙必须依赖计时器来清理旧状态。

维护（Maintenance）与 Keep-alive：

由于防火墙的内存资源是有限的，状态表不能无限膨胀。因此，对于 UDP 会话，如果一段时间内没有数据流过，防火墙就会认为会话已结束并删除对应的状态条目。根据 Tailscale 的研究，这个超时阈值通常非常短，业界通用的经验值约为 30秒 1。

这一特性对应用程序开发提出了严格要求：为了保持 P2P 连接的“活性”，应用程序必须周期性地发送“心跳包”（Keep-alive packets）。如果静默时间超过 30 秒，防火墙就会“遗忘”这个连接，后续的入站数据包将被视为非法的、未经请求的流量而被丢弃。

2.3 防火墙对决（Firewall Face-Off）的死锁困境

当两台均位于有状态防火墙背后的设备（Peer A 和 Peer B）试图建立直接连接时，会陷入典型的“死锁”场景，被称为“防火墙对决”：

1. Peer A 的尝试：Peer A 向 Peer B 发送握手包。该包穿过 Peer A 的防火墙，在 Peer A 侧建立了出站状态。然而，当包到达 Peer B 的防火墙时，由于 Peer B 尚未向 Peer A 发送过任何数据，Peer B 的防火墙在状态表中找不到匹配项，因此判定该包为“未经请求的入站流量”，将其直接丢弃。
2. Peer B 的尝试：与此同时，Peer B 也向 Peer A 发送握手包。同样，该包在 Peer B 侧建立了状态，但在到达 Peer A 的防火墙时，因为 Peer A 的防火墙只记得“我发给过 B”，而不记得“B 发给过我”（实际上 Peer A 确实发过，但 Peer A 的防火墙逻辑是基于接收到的有效回包来确认连接建立，或者更严格地说，Peer A 的防火墙虽然有出站记录，但 Peer B 的包可能因为时序问题被 Peer A 的防火墙视为无关流量，或者在更常见的情况下，双方互发时，如果只是简单的串行尝试，必败无疑）。

为了打破这种僵局，必须引入一种机制，让双方的防火墙都认为自己是“主动发起方”，或者至少认为对方的入站包是对自己出站包的“回复”。这就是后续“打洞”技术的基础。

3. 网络地址转换（NAT）：地址映射的迷宫

NAT 设备通常具备有状态防火墙的所有特性，除此之外，它们还增加了一层复杂性：修改数据包的源或目的 IP 地址及端口。最常见的 NAT 类型是源网络地址转换（SNAT），它允许多个内网设备共享一个公网 IPv4 地址。

3.1 NAT 的基本运作原理

当内网设备（例如 192.168.0.5:5000）向公网发送数据包时，NAT 设备会拦截该数据包，将其源 IP 修改为 NAT 设备的公网 IP（例如 203.0.113.1），并将源端口修改为一个临时分配的公网端口（例如 15000）。同时，NAT 设备会在内部维护一张“映射表”，记录 {内网IP:端口} <-> {公网IP:端口} 的对应关系。当公网的回包到达 203.0.113.1:15000 时，NAT 设备查表，将目标地址还原为 192.168.0.5:5000 并转发给内网设备。

3.2 NAT 映射行为分类：EIM 与 EDM

理解 NAT 穿透的关键在于区分 NAT 如何分配公网映射。RFC 4787 定义了多种 NAT 行为，但在工程实践中（如 Tailscale 的分类），通常将其简化为两大类：端点独立映射（Endpoint-Independent Mapping, EIM）和端点相关映射（Endpoint-Dependent Mapping, EDM）。这种分类直接决定了 NAT 穿透的难度。

3.2.1 端点独立映射 (EIM) - "Easy NAT"

在 EIM 模式下，NAT 设备的映射逻辑仅依赖于内网源地址和端口。

• 行为特征：只要内网主机使用同一个源端口（如 192.168.0.5:5000）发送数据，无论它发往公网上的哪个目标 IP（服务器 A 或 服务器 B），NAT 设备总是为其分配同一个公网映射（如 203.0.113.1:15000）。
• 穿透意义：这被称为“Easy NAT”。因为一旦 Client A 通过任何方式（如 STUN 服务器）得知了自己的公网映射 203.0.113.1:15000，它就可以确信，当它向 Client B 发送数据时，Client B 看到的源地址也一定是 203.0.113.1:15000。这使得交换连接信息变得简单可靠。

3.2.2 端点相关映射 (EDM) - "Hard NAT"

在 EDM 模式下，NAT 设备的映射逻辑不仅依赖于内网源，还依赖于目标地址。

• 行为特征：
  • 当 192.168.0.5:5000 发往 STUN 服务器（1.1.1.1:3478）时，NAT 分配公网端口 15000。
  • 当 192.168.0.5:5000 发往 Client B（2.2.2.2:4000）时，NAT 会检测到目标不同，因此分配一个新的、不同的公网端口，例如 15001。
• 穿透意义：这被称为“Hard NAT”。Client A 向 STUN 服务器查询到的地址 15000 对连接 Client B 毫无用处。因为当 A 真正向 B 发包时，源端口变成了 B 未知的 15001。这直接废掉了传统的地址发现机制，使得穿透变得极其困难。

4. STUN：地址发现的先锋

为了穿透 NAT，设备首先必须解决“我是谁”的问题。在内网中，设备只知道自己的私有 IP，这对于公网通信毫无意义。STUN（Session Traversal Utilities for NAT）协议应运而生。

4.1 STUN 的技术实现

STUN 协议（RFC 5389）定义了一种轻量级的请求/响应机制。

1. 请求：位于 NAT 后端的客户端向公网上的 STUN 服务器发送一个绑定请求。
2. 处理：STUN 服务器接收到请求后，查看 IP 包头中的源 IP 和源端口——这正是经过 NAT 修改后的公网地址。
3. 响应：STUN 服务器将观察到的公网 IP 和端口打包在响应消息的数据载荷（Payload）中，发回给客户端。
4. 获知：客户端解析响应，从而得知自己在公网上的“面貌”。

4.2 STUN 的局限性与失效场景

STUN 是 NAT 穿透的基础工具，但它并非万能药。其有效性完全取决于 NAT 的类型。

• 在 EIM 环境下：STUN 完美工作。客户端发现的公网地址是静态的，可以安全地通过信令通道告诉任何对端（Peer），对端向该地址发包即可到达客户端的 NAT。
• 在 EDM 环境下：STUN 仅能告诉客户端“刚才那个特定连接”的映射。如果客户端试图利用这个信息去连接其他 Peer，NAT 会分配新的映射，导致之前的 STUN 结果失效。因此，对于 Hard NAT，STUN 只能起到辅助作用（如判断 NAT 类型），而无法直接用于建立连接 ¹。

此外，STUN 无法穿越某些阻止 UDP 流量的防火墙，也无法解决 TCP 连接中的复杂状态同步问题（尽管有 TURN-TCP 等变体，但 UDP 仍是 P2P 的首选）。

5. 打洞（Hole Punching）：穿越防线的技巧

当双方都知道了（或猜测到了）对方的公网地址后，真正的挑战开始了：如何欺骗双方的防火墙，让它们都以为自己在处理“合法的出站连接的回包”。这种技术被称为“打洞”（Hole Punching），Tailscale 形象地将其描述为利用“同步传输”（Simultaneous Transmission）来“巧妙应对防火墙”（Finessing Firewalls）。

5.1 侧信道与协调服务器（Coordination Server）

在任何 P2P 流量开始之前，必须存在一个双方均可达的“侧信道”（Side Channel）。在 Tailscale 的架构中，这个角色由协调服务器（Coordination Server）扮演（也就是控制平面）。

• 信息交换：Peer A 和 Peer B 登录到协调服务器，交换各自通过 STUN 发现的公网 IP:Port 列表。
• 同步指令：协调服务器不仅传递地址，还可以传递时序信号，帮助双方大致同步地开始连接尝试。

5.2 同步传输的详细流程

打洞的核心在于利用时间差，制造出“双向都是主动发起”的假象。

1. 准备阶段：Peer A 和 Peer B 通过协调服务器获知对方的公网地址。
2. 同步发射：Peer A 和 Peer B 几乎在同一时刻，向对方的公网地址发送 UDP 探测包。
3. Peer A 的视角：
   • Peer A 发出包，其 NAT/防火墙创建了一个出站规则：Src: Internal_A -> Dst: Public_B。这意味着防火墙现在允许来自 Public_B 的流量进入，只要它匹配这个会话。
4. Peer B 的视角：
   • Peer B 发出包，其 NAT/防火墙也创建了一个出站规则：Src: Internal_B -> Dst: Public_A。防火墙现在允许来自 Public_A 的流量进入。
5. 穿越与到达：
   • 假设 Peer A 的包先到达 Peer B 的防火墙。如果 Peer B 的出站包还没发出去，Peer A 的包可能会被丢弃（防火墙认为是非法入站）。
   • 但在大多数情况下，只要 Peer B 的包也发出了，Peer B 的防火墙就已经有了“允许来自 Public_A”的状态记录。
   • 当 Peer A 的包到达时，Peer B 的防火墙检查状态表，发现匹配项（虽然是 Peer B 发起的，但 UDP 状态匹配通常只看 IP:Port 对），于是放行。
   • 同理，Peer B 的包到达 Peer A 时，Peer A 的防火墙也因为之前的出站记录而放行。
6. 连接建立：一旦第一对数据包穿过防火墙被对方接收，后续的双向通信就畅通无阻了，因为双方的 NAT 状态都已“激活”并被双向流量维持。

这一过程不仅解决了防火墙阻断问题，也解决了 NAT 映射的建立问题（在 EIM 情况下）。

6. 应对 Hard NAT：生日悖论与暴力破解

当连接的一方或双方位于 Hard NAT（EDM）之后，情况变得极其棘手。因为对于 Hard NAT，无法预知它会为 P2P 连接分配哪个公网端口。此时，Tailscale 采用了一种基于统计学原理的激进策略——利用生日悖论（Birthday Paradox）。

6.1 问题空间：为什么 Hard NAT 如此困难？

• 单边 Hard NAT：如果 Peer A 是 Hard NAT，Peer B 是 Easy NAT。虽然 A 的端口不可知，但 B 的端口是固定的（通过 STUN 可知）。A 可以主动向 B 的固定端口发包。B 收到包后，就看到了 A 的“真实”公网地址（即 NAT 为 A->B 连接分配的那个特定端口），然后 B 回复该地址即可。这种场景相对容易解决。
• 双边 Hard NAT：这是噩梦场景。Peer A 不知道 Peer B 在哪里监听（因为 B 的 NAT 会为来自 A 的流量分配新端口），Peer B 也不知道 Peer A 在哪里。
  • 搜索空间爆炸：每个 NAT 有 65,535 个可能的端口。如果只是盲目猜测，找到正确的 {A_Port, B_Port} 组合的概率是 $1/65535 \times 1/65535$，几乎为零。

6.2 生日悖论的应用逻辑

生日悖论告诉我们，在一个集合中，只要选取相对少量的样本，两样本相同的概率就会变得惊人地高。在 NAT 穿透中，我们不需要“猜中”对方的具体端口，而是通过发送大量的探测包，增加双方“碰巧”撞上对方正在监听的端口的概率。

• 具体实施：
  • Tailscale 客户端会生成大量的探测包，发往对方可能的端口范围。
  • 不仅仅是猜端口，而是利用 Hard NAT 的一些端口分配规律（虽然是随机的，但往往在一定范围内）。
  • 双方同时进行这种“地毯式轰炸”般的探测。

6.3 概率与性能数据

根据 Tailscale 的研究数据，这种暴力破解方法的效率比直觉要高得多 ¹：

数据分析：

• 搜索空间的平方效应：在双 Hard NAT 场景下，搜索难度是单边的平方级。
• 时间成本：虽然 9 分钟对于建立一个连接来说非常漫长，但相比于理论上的完全穷举（可能需要 1.2 年），生日悖论将不可能变成了“勉强可能”。
• 网络负载与设备压力：这是该方法的巨大副作用。发送 170,000 个探测包意味着在短时间内创建大量的 NAT 会话。许多家用路由器或小型企业防火墙（如 Juniper SRX 300 系列）的会话表容量有限（例如 64,000 条）。这种暴力探测极易占满会话表，导致路由器拒绝服务，甚至崩溃 ¹。

因此，生日悖论攻击通常作为最后的手段，且需要谨慎控制发包速率，以免摧毁用户的网络硬件。

7. 中继（Relaying）与 DERP：最后的防线

当打洞失败（例如双边 Hard NAT 且用户不愿等待 28 分钟），或者网络环境过于恶劣（如严格的 Symmetric NAT 且限制了 UDP 发包速率），P2P 连接在物理上无法建立。此时，系统必须回退到中继模式。

7.1 标准中继：TURN 协议

TURN（Traversal Using Relays around NAT）是工业标准的解决方案。

• 机制：当 P2P 失败时，Peer A 和 Peer B 共同连接到一个公网上的第三方服务器（Relay Server）。Peer A 将数据封装后发给服务器，服务器解封并转发给 Peer B，反之亦然。
• 缺点：
  1. 高延迟：数据包不再走最短路径，而是必须绕道中继服务器。
  2. 带宽成本：中继服务器必须处理所有流量，这对服务提供商来说意味着巨大的带宽账单。
  3. 单点故障风险：中继服务器的稳定性直接影响连接。

7.2 Tailscale 的创新：DERP (Detour Encrypted Routing Protocol)

Tailscale 没有直接使用现成的 TURN 协议，而是设计了自定义的 DERP 协议 ¹。

DERP 的设计哲学与优势：

1. 全球分布式部署：Tailscale 在全球各地部署了大量的 DERP 服务器群组。这不仅仅是中继，更是一个覆盖全球的软件定义网络（SDN）。
2. 总是可用（Always-On）：与传统的“P2P 失败后才启用 TURN”不同，Tailscale 在尝试打洞的同时，就已经建立了 DERP 连接。
   • 这意味着连接是即时的。用户点击连接的一瞬间，数据通过 DERP 传输，没有等待打洞的时间。
   • 一旦后台的 P2P 打洞成功，流量会自动、无缝地切换到直连路径，此时延迟降低，吞吐量提高。用户体验极其流畅。
3. 安全性：DERP 仅作为一个盲目的数据包转发器。它转发的是经过 WireGuard 加密的密文。DERP 服务器本身没有私钥，无法解密用户数据。这保持了端到端的零信任安全模型。
4. 应对 HTTPS 封锁：DERP 流量通常运行在 TCP 443 端口上，伪装成普通的 HTTPS 流量，这使得它极难被防火墙（如 DPI）阻断。

8. ICE：统管全局的指挥家

上述所有技术——STUN 地址发现、端口预测、打洞、DERP 中继——并非孤立存在，而是由 ICE（Interactive Connectivity Establishment）协议统一编排的。Tailscale 虽然没有完全照搬标准的 ICE 状态机，但其核心逻辑与 ICE 高度一致，WebRTC 也使用了类似的机制 ¹。

8.1 ICE 的“锦囊妙计” (Bag of Tricks)

ICE 可以被视为一个决策引擎，它的工作流程如下：

1. 候选地址收集（Candidate Gathering）：
   • ICE 引擎会收集本地接口的所有 IP（Host Candidates）。
   • 通过 STUN 查询公网 IP（Server Reflexive Candidates）。
   • 获取中继服务器的地址（Relayed Candidates）。
2. 连通性检查（Connectivity Checks）：
   • ICE 将所有可能的 {本地候选, 远端候选} 组合成对。
   • 它按照优先级对这些对进行排序。通常：IPv6 直连 > IPv4 LAN 直连 > IPv4 WAN P2P > 中继。
   • ICE 引擎并发地向这些候选对发送 STUN 绑定请求，测试连通性。
3. 路径选择与升级：
   • 一旦发现一条可用的路径，ICE 就会立即使用它（通常最先连通的是中继）。
   • 随着测试的进行，如果发现了一条更高优先级的路径（例如打洞成功了），ICE 会将流量平滑地迁移到新路径上。

8.2 信令通道的重要性

ICE 的运作高度依赖于一个能够交换候选地址信息的信令通道（Signaling Channel）。在 WebRTC 中，这通常是 WebSocket；在 Tailscale 中，这就是通过协调服务器建立的加密控制通道。没有这个通道，Peer 之间无法交换“我在哪里”，ICE 也就无从谈起。

9. Tailscale 的综合实现架构与洞察

Tailscale 将上述理论完美地融合在其产品中，形成了一个独特的连接架构。通过分析其实现，我们可以获得关于现代网络架构的深层洞察。

9.1 控制平面与数据平面的分离

Tailscale 严格遵循 SDN 的设计原则，将控制平面与数据平面分离：

• 控制平面（Coordination Server）：负责公钥的分发、策略（ACL）的下发、节点状态的同步。它类似于一个“公共的投递箱”，只处理轻量级的元数据，不接触任何用户数据流量。这解决了中心化架构的扩展性瓶颈。
• 数据平面（Data Plane）：基于 WireGuard 的网状网络。数据直接在节点间传输（P2P），或者通过 DERP 中继。由于 WireGuard 的高效性，数据平面的性能损耗极低。

9.2 零信任与安全性

Tailscale 的设计体现了极致的“零信任”（Zero Trust）原则。

• 私钥本地化：私钥在节点本地生成并存储，永远不会离开设备。协调服务器只持有公钥。这意味着即使协调服务器被黑客攻破，攻击者也无法解密用户流量，只能看到元数据 ¹。
• 分布式防火墙：虽然 ACL 策略由中心服务器管理，但执行是在每个节点的接收端进行的。这意味着即使攻击者攻破了 NAT 防线，如果没有正确的密钥和符合 ACL 的策略，数据包依然会被内核层的 WireGuard 接口拒绝。

9.3 为什么 Tailscale 能成功？

Tailscale 的成功不仅在于技术的先进性，更在于它解决了碎片化的问题。

• 兼容性：它不再假设网络是理想的，而是假设网络是充满敌意的（Hard NATs, Firewalls, IP 变化）。
• 自动化：它将复杂的 NAT 穿透逻辑（STUN, 生日悖论, DERP 切换）封装在驱动层，对用户完全透明。用户看到的只是一个始终在线的虚拟网卡。

10. 结论与未来展望

NAT 穿透技术是现代互联网在地址短缺与安全需求夹缝中生长出的复杂生态。从基础的防火墙状态欺骗，到 STUN 的地址发现，再到利用生日悖论暴力破解 Hard NAT，以及最终兜底的 DERP 中继，每一层技术都是对现有网络限制的突围。

核心总结与专家洞察：

1. 连接的代价：网络连接不再是免费的资源。建立连接需要付出代价：要么是计算资源的消耗（生日悖论的暴力搜索），要么是网络基础设施的成本（中继服务器的带宽），要么是工程实现的极度复杂性（ICE 的状态机维护）。
2. UDP 的主导地位：现代 P2P 技术极度依赖 UDP。TCP 的三次握手和严格状态机在面对 NAT 的欺骗技巧时显得过于僵化。UDP 的无连接特性允许应用程序在用户态灵活控制包的发送时序，这是“打洞”能够成功的关键。
3. IPv6 的终局：尽管 NAT 穿透技术已经炉火纯青，但它本质上是对 IPv4 架构缺陷的“补丁”。随着 IPv6 的普及，NAT 问题将最终消失（因为每个设备都有全球唯一的公网 IP），但有状态防火墙仍将存在。未来的连接技术将从“如何找到对方”转向“如何安全地验证对方”，重点将从 NAT 穿透转移到身份认证与零信任策略的协商上。

本报告通过详尽拆解 Tailscale 的技术实践，展示了在不完美的互联网基础设施之上，构建完美互联体验的可能性。这对于网络架构师、协议开发人员及企业 IT 决策者理解现代网络通信的底层逻辑具有重要的参考价值。

关键术语表：

• Stateful Firewall: 有状态防火墙
• SNAT (Source NAT): 源网络地址转换
• EIM (Endpoint-Independent Mapping): 端点独立映射 (Easy NAT)
• EDM (Endpoint-Dependent Mapping): 端点相关映射 (Hard NAT)
• STUN: NAT 会话穿透实用工具 (Session Traversal Utilities for NAT)
• TURN: NAT 中继穿透 (Traversal Using Relays around NAT)
• ICE: 交互式连接建立 (Interactive Connectivity Establishment)
• DERP: Tailscale 自研的中继协议 (Detour Encrypted Routing Protocol)
• WireGuard: 高效的现代 VPN 协议
• Coordination Server: 协调服务器 (控制平面核心)

参考文献与来源索引：

1 Tailscale Blog: How NAT Traversal Works & How Tailscale Works

1 Tailscale Blog: Direct Connections & Birthday Paradox details

RFC 4787, RFC 5389, RFC 8445 (Contextual Technical Standards)