摘要

  • RFC 3424 指出 NAT 并不存在唯一的“外面”；反射服务返回的是某个观察者在某一地址域、某一时刻看到的映射。
  • 临时穿越办法若没有有限范围、退出路线、脆弱性清单、长期方案要求与部署经验，就会因持续成功而获得永久预算。

保活每二十秒发送一次。映射没有消失，通话也大多能建立。监控于是把这条链路标成稳定。

但稳定的究竟是什么？不是端点拥有的地址，也不是防火墙作出的长期许可，而是一组持续供电的假设：NAT 继续采用相同映射行为，反射或中继服务继续在线，路径没有更换，计时器没有缩短，远端仍从相同地址域观察，应用仍接受最后的会话。

RFC 3424 于 2002 年 11 月以 IAB Informational 文档发布，讨论 UNSAF，也就是端点跨越 NAT 单方面发现或修正自身地址的办法。它没有把这种做法塑造成标准答案。相反，文档把它称为 heuristic 和 workaround，要求每个提案在投入使用前说明如何限制自己、如何退出。

NAT 没有唯一的外面

地址转换状态保存在转换设备内部。端点可以向另一个地址域中的服务发送报文，请对方返回所见源地址与端口。这个结果有证据价值，但它的主语必须保留：是该服务看见了这个 tuple。

若最终目标位于另一条路径、另一层 NAT 或另一策略边界后，它可能看见不同映射，也可能根本收不到流量。反射地址因此不能自动升级为“公网地址”。它不证明目标相对可达、映射稳定、入站获准、传输建立或应用结果。

即使反射服务对回应签名，也只会加强发言者身份，不会扩大结论范围。“我在时间 T 看见 X”依旧不等于“任何目标都能在未来通过 X 到达端点”。观察真实性与普遍有效性是两条证据轴。

这也是 public 一词容易制造的误导。它把观察位置、路径和时间压缩成一个仿佛属于端点的永久属性，而 RFC 3424 恰恰提醒设计者：不存在一个天然、唯一的 outside。

保活保存的是假设

NAT 可能回收或改变 mapping。无连接传输尤其可能遇到不可预测的绑定变化。为了维持可用性，客户端会发 keepalive、重新查询反射服务，双方也可能保存推测状态。

每增加一次维护动作，系统都多了一项运行义务。反射服务必须可解析、可路由、可扩容并抵御滥用；客户端要处理重试、计时和切网；运维要区分旧映射、目标差异、策略阻断和应用拒绝。原本两端之间的通信，开始与第三个服务 fate-sharing。

保活成功只证明某个维护动作在某条路径上得到结果。它不证明中间盒正式授权后续入站，也不证明另一目标复用相同绑定。反射服务没有 NAT 的内部知识，只能假设过去行为可以预测未来。

当组织只计算最终接通率时，保活成本会被误写成网络天然属性。临时机制不再需要续期，因为它的存在本身让失败减少；失败减少又被用来证明机制合理。退出激励被成功指标反向消灭。

穿越不是授权

RFC 3424 的安全边界并非“穿越都不安全”，而是缺少显式中间盒通信时，UNSAF 无法确保通信在设备策略监督下通过。发现映射、维持绑定、完成候选对检查、建立传输、通过应用认证，是五张不同收据。

一条报文偶然通过不能代表永久许可。一个开放 mapping 也不能说明防火墙为何开放、谁批准、何时撤回。若应用通过观察副作用绕过无法查询的控制面，它可能削弱中间盒本来承担的安全功能。反过来，运营者若要求应用依赖不可见规则，也让应用无法解释失败。

合理的设计应让策略具有明确接口或至少明确证据边界。把“过去穿过一次”当成“已被授权”，就是让行为预测替代治理决定。

临时方案必须回答五个问题

第一，问题是否足够具体且有限。若目标被写成“让所有应用穿越任何 NAT”，workaround 就没有自然终点。有限场景能清楚列出不覆盖的对象与失败模式。

第二，退出或过渡方案是什么。真正临时的机制应随着正确技术部署而自然减少使用。退出需要负责人、阈值、期限与可执行的移除测试，而不是路线图上的一句未来计划。

第三，脆弱性是否入账。额外服务、跨层状态、调试成本、迁移顺序与故障耦合都属于产品成本，不能只展示 happy path。

第四，临时运行产生了哪些长期方案要求，并由谁推动实现。若 workaround 只积累用户、不积累替代设计，它提供的是锁定，不是桥梁。

第五，部署中实际存在的 NAT 行为和经验是什么。运行代码必须约束架构主张，但一次成功同样不能推出普遍规律。

五问共同改变了审批对象。评审的不只是“它能否启动”，更是“什么证据会使它失去继续存在的权力”。

后来的协议把主张缩小了

早期 RFC 3489 对 STUN 的定位更广。RFC 5389 取代它，把名称调整为 Session Traversal Utilities for NAT，并撤回 STUN 本身就是完整穿越方案的暗示；具体 usage 必须描述外围机制与安全处理。RFC 8489 继续修订这个工具，也没有把 server-reflexive address 变成通用身份。

ICE 的结构更接近证据链。它收集 host、server-reflexive 与 relayed candidates，交换后逐对检查。最终 selected pair 证明的是某次 ICE session 的特定连通结果。它不证明该地址对所有目标有效，也不保证下次网络变化后继续成立，更不代表应用已经接受业务。

PCP 通过显式请求 mapping，改善了另一条边界：端点不再只靠副作用猜测设备行为。不过，获批 mapping 仍不等于远端接受或最终应用结果。明确控制与端到端收据不能合并。

这些机制的重要进步不是找到一个万能答案，而是选择更窄的名词：utility、candidate、check、selected pair、requested mapping。主张越窄，失败越容易归属，未来替换越可行。

十二张收据

第一张记录本地接口与传输 tuple。第二张记录反射服务身份、路径与地址域。第三张保存反射 mapping、时间和寿命假设。第四张是中间盒显式规则或授权，如果确实存在。

第五张来自目标：它实际看见什么。第六张是候选对 connectivity check。第七张证明传输建立。第八张证明经过认证的应用交换。第九张记录用户或服务结果。任何后层成功都不应反向替前层背书。

第十张覆盖 retry、expiry、切网和路径变化。第十一张写明例外所有者、范围与 retirement trigger。第十二张最容易缺失：证明 workaround 的使用比例确实下降，或者已经结束。

如果最后一张不存在，“临时”只描述了批准会议的语气，而不是系统状态。

证据边界

RFC 3424 不是今日 NAT 部署普查，也没有证明任何厂商、运营商、应用或真实事故的行为。它没有宣布 IPv6、STUN、TURN、ICE 或 PCP 是统一出口。反射地址不是端点身份，连通检查不是应用授权，保活也不是稳定策略。

Heng Lu 的最小初始规范、未来决策本地化、自愿采用与 running-code primacy 在这里作为公开分析视角，而不是部署证据。最小工具可以存在，但必须保持边界，让未来采用仍由本地决定；运行结果可以修正主张，却不能把一次成功扩大为永久权力。

真正需要退出的并不是某个数据包格式，而是“反射等于地址、保活等于稳定、接通等于正确”的推理捷径。

来源