为什么同一个内网，有人能直连有人只能中转？
排查远程访问链路时最容易卡住的一环，不是带宽也不是防火墙，而是 NAT 类型。两台设备能否建立 P2P 直连，取决于它们各自出口 NAT 的行为差异。当外网 Client 尝试访问企业内网 Server 时，Server 所在的 NAT 设备如何分配端口、如何处理入站包，直接决定了打洞是否能成功。
NAT 的核心工作只有两件事：地址转换和端口映射。但不同设备对端口映射的策略差异巨大。映射规则不事先声明，Client 就无法预测 Server 在公网侧的实际监听端点，打洞过程就变成了盲猜。所以先厘清 NAT 分类，再谈成功率才有意义。
四种 NAT 类型怎么区分？端口映射行为是关键
RFC 3489 定义的四种 NAT 类型，本质上是两个维度的组合：入站过滤规则、端口分配规则。理解这两条规则，就能解释大部分打洞失败现象。
| NAT 类型 | 端口分配规则 | 入站过滤规则 | P2P 打洞可行性 |
|---|---|---|---|
| Full Cone（全锥形） | 同一内网端点始终映射到同一公网端点 | 任意外部主机都可向该公网端点发包 | 极易成功 |
| Restricted Cone（受限锥形） | 同一内网端点始终保持同一公网端点 | 仅允许内网主机先前发送过数据的外部 IP 入站 | 较易成功 |
| Port Restricted Cone（端口受限锥形） | 同 Restricted Cone | 仅允许内网主机先前发送过数据的外部 IP:端口 入站 | 中等难度 |
| Symmetric（对称型） | 每个目标 IP:端口 分配不同的公网端口 | 同 Port Restricted Cone | 极难成功 |
真正的分水岭在于对称型。对称 NAT 分配端口的依据是目标地址，访问 A 服务器时映射 30401 端口，访问 B 服务器时又是 41277。打洞方根本拿不到一个稳定的公网端点去让对端“预判”。而 Full Cone 环境下，一旦内网端点主动向外发过一次包，公网映射就固定下来，任何人都能顺着这个映射进来。
实际操作中判断 NAT 类型不需要抓包分析，可以用简单的逻辑试探：从同一内网端点分别向两个不同公网服务器发包，如果两台服务器观察到的源端口相同，则端口分配是锥形的；如果不同，就是对称型。入站过滤规则则通过第三方主机发包测试即可确认。
打洞成功率到底卡在哪一步？
P2P 打洞的标准流程只两步：
- 双方各自与中转服务器建立连接，注册自己的公网端点信息。
- 服务器将一方的公网 IP:端口 告知另一方，双方同时向对端公网端点发包，让对方 NAT 记录“我这边刚主动访问过它”，从而放行后续入站流量。
在锥形 NAT 下，第二步几乎必然成功，因为只要内网端点对某个外部地址发过包，NAT 过滤规则就会放行该地址的回包。问题就出在对称 NAT：设备 A 的 NAT 对设备的公网端点发包时，分配的是端口 X1；而对另一端的端点发包时，分配的是端口 X2。Server 端从信令服务器拿到的，是 X1 还是 X2，完全不受控制。一旦信息不对等，双方发的“打招呼”包都进不了对方的过滤表，打洞就失败了。
企业内网侧的 NAT 行为通常不受运维团队控制。运营商光猫默认配置、上级汇聚设备的 NAT 策略、安全网关的 EIM 参数（Endpoint-Independent Mapping）都会影响最终类型。部分设备即使支持 EIM，还需要手动开启，多数默认关闭。问题变成了：你无法保证对端设备的 NAT 不是对称型。
实际部署中如何规避对称 NAT 的影响？
业内处理对称 NAT 的标准做法是端口预测算法，前提是 NAT 设备的端口分配存在线性或可学习的规律。但这个方法在遇到随机端口分配的商用设备时会直接失效，所以有应用经验的方法一般分层：先判断类型，再决定策略。
- Full Cone / Restricted Cone：直接按标准打洞流程进行。成功率极高，适合默认策略。
- Port Restricted Cone：打洞双方需要各自向对方可能映射到的多个端口同时发包，端口范围需要基于先前的映射记录做推测。复杂度上升，但仍有实践价值。
- Symmetric：放弃打洞，直接回退到中继转发。这个决策必须提前做出，不能等打洞失败超时后再切换，否则用户体验会非常差。
这里补充几点实际操作中容易忽略的事实：
- 即便是同型号设备，装载了不同固件版本，NAT 行为可能完全不同。
- 同一个设备对不同协议的打洞通过率不固定，UDP 打洞远比 TCP 容易。
- 有些企业在出口部署了多级 NAT，公网观测到的类型是嵌套后的复合结果，只会更复杂。
[插图建议：立体流量图展示 Server 内网端、NAT 设备、公网 Client、信令服务器四方在不同 NAT 类型下的端口映射差异]
NexTunnel 的链路策略：不把成功概率押在 NAT 类型上
理解了 NAT 类型的不确定性，再回看远程访问设计就有实际意义。NexTunnel 的方案把判定与切换做成自动链路。
实际使用流程是：在企业内网侧安装 NexTunnel Server，外网办公电脑安装 NexTunnel Client。Client 连接时，先尝试通过信令机制建立 P2P 直连；信令信息中包含着双方的公网端点预估。若两端 NAT 探测结果显示为兼容的锥形组合，直接建立直连通道。一旦出现对称型 NAT 或端口分配异常，则立即切换到中继转发模式，走部署在中转节点的加密隧道流转。
这种组合的价值在于对 P2P 打洞没做成“必须成功”的承诺，而是保留了通路。在有私有化中继部署条件的企业，中继节点放自己的机房，延迟与带宽都可以按业务需求量身调整。而 Client 侧展示的是同一条访问入口，不需要用户关心具体走的是哪条链路，这一点对于运维人员来说尤其重要：不用再把“远程卡顿”和“对方 NAT 类型复杂”混在一起来排查。
配合端口层面的控制，NAT 探测结果也可以作为审计依据。后台授权某台 Client 访问内网中的 GitLab 或 MySQL 资源时，指定端口范围；直连通道建立后按端口放行。对于走中继的场景，访问记录一样下发到审计记录里，保留链路类型和端点的决策过程。
实用排查清单：遇到打洞失败从哪里下手？
远程连不上内网时，把问题切成三段来查：类型的判定有没有问题、策略回退是否触发、策略生效前的空隙是否被误用了。下面这份清单按优先级排序：
- 确认客户端与 Server 端的 NAT 行为探测结果是否一致。曾有场景是，一侧检测为锥形，另一侧设备实际按对称型分配端口，导致打洞半成功后又断开。
- 如果链路自动回退到中继，检查中继节点与两端网络之间的往返延迟是否超过设计阈值。中继选点不当会让可达性保持但体验大幅倒退。
- 重点排查端口释放延迟问题：部分 NAT 设备在打洞阶段的临时映射未及时刷新，目标服务端口在它处被复用。
- 断开重连后有没有复现？一次成功的打洞之后，端口映射可能被设备保留数分钟，掩盖了本来就不稳定的组合。
- 在后台查看审计记录里与该 Client 会话对应的直连/中继标识，如果多次会话总是被强制中继，说明该侧出口设备大概率属于对称型，需要评估是否替换设备或接受中继性能。
下一步落地建议
不要把时间耗在手工判断每一台出口设备的 NAT 类型上，链路选择应该做成自动判定。需要远程访问内网系统时，优先采用 Server 内网侧部署、Client 外网访问、自动 P2P/中继切换的架构；在关键业务上启用设备授权加端口控制，把安全策略绑定到访问层而不是网络层。NexTunnel 的链路策略正好能覆盖这类需求，可以先用它做一个低配置的中继节点测试，对比 P2P 与中继两种模式在各业务系统中的实际表现。