摘要

  • RFC 5128 是对当时实际使用的点对点 NAT 穿越技术所作的描述性记录，并不构成对某种实现的背书。
  • 协调服务可以分发参与者声明的私网和公网端点，却不能只靠公网注册交换验证其私网地址。
  • 同一个私网地址在不同家庭、办公室或级联 NAT 中可以指向完全不同的设备。
  • 对声明私网地址发出的穿越探测，可能抵达发送者局域网中的另一台主机；即使无人恶意操作，也会发生这种混淆。
  • 恶意注册者可以填入受害者地址，使大量对等方把连接尝试集中到该目标。
  • 在完成经过认证的双向通信之前，应用应限制数据包、字节、重试、扇出、计算和状态存储。
  • 某个端点作出响应，只证明一条路径上的某个对象应答，并不证明预期的人、账户、机构或权限。
  • 仅认证源 IP 无法解决问题，因为兼容 NAT 的信令本来就必须容忍地址改写，路径上的参与者也可能替换地址。
  • 应用需要使用更高层身份认证真实内容，并把该身份绑定到所选路径；加密能保护内容，但未必消除流量分析。
  • 端点无关映射与端点无关过滤是两种属性；映射可以复用，不代表 NAT 对任意入站来源开放。
  • 后来的 ICE 连通性检查和 TURN 中继分配完善了路径机制，却没有自动生成用户身份、授权或业务结果凭据。
  • 领导者应分别保存注册、发现、探测预算、路径建立、对等方认证、授权、资源投入与交付结果的凭据。

相同数字，属于不同的地址现实

设想两个家庭都使用 192.168.1.100。在甲家，这个地址属于参与视频通话的笔记本；在乙家，它也许属于打印机、摄像头、存储设备，甚至某台与通话完全无关的工作站。地址在各自的私网中都有效，却没有全局唯一含义。

当参与者向协调服务登记私网端点和 NAT 转换后可见的公网端点时，服务可以确认账户完成了注册，也可以记录它观察到的公网源元组。但服务无法透过所有参与者的局域网，证明登记的 192.168.1.100 在另一个对等方所处的地址域中仍然指向原来的设备。

如果接收者优先尝试看似更近的私网候选，数据包会由接收者所在网络解释这个地址。声明者的意图并不参与路由决策。于是，一份形式正确的发现结果可能把探测送往错误的本地主机。错误主机可以沉默、记录、拒绝，也可能应答足够多的协议步骤，让控制面误以为路径已经建立。

这里至少存在五层现实。注册说明某个值被声明；发现说明该值被分发；NAT 与路由说明数据包实际去了哪里；经过认证的应用交换说明谁掌握所需身份凭据；应用结果说明有用工作是否完成。把这五层都压缩成“已连接”，就会失去调查与治理所需的因果链。

协调服务转发声明，不为声明加冕

协调服务的价值十分明确：位于 NAT 后的对等方通常无法直接知道彼此的转换端点，服务可以观察公网元组、整理候选地址并帮助双方开始探测。这是一种范围狭窄而有效的协调功能。

风险始于输出被抬升为权威。即使发现响应带有服务自己的签名，它最多证明服务向某个会话发出了这组候选。它不能证明每个候选都由目标对等方控制，也不能证明私网候选在接收者的地址域里保持原义，更不能证明最终响应者就是注册时那个账户背后的人或机构。

RFC 5128 因而要求在完成经过认证的双向通信之前，把新发现的地址视为可疑。认证采用什么协议由应用决定，但时间边界必须清楚：认证之前，端点只是可以用严格预算测试的目的地，而不是要求系统执行昂贵工作的资格证明。

候选还需要保留来源。它是参与者自行声明的主机地址，是服务看到的公网源地址，是连通性检查学到的对等反射地址，还是中继服务分配的地址？不同来源提供不同强度的事实。来源标签不能让地址自动可信，但缺少它，事后就无法解释系统为何选择、排序或继续使用某个端点。

认证前预算不是性能参数，而是安全边界

穿越机制不可能在完全没有初始通信的情况下发现路径，因此问题不是消灭所有认证前流量，而是限制一个未经验证的声明能使其他参与者发送多少数据、执行多少计算、保留多少状态。

RFC 5128 明确提醒应用，向新发现地址发送的流量应在大小和速率上保持最小。恶意参与者可以登记受害者的地址；如果这份登记被大量对等方发现，连接尝试便会集中到受害者。攻击者不必亲自发出所有数据包，协调机制会替它招募发送者。

只计算线上字节还不够。每次尝试可能创建计时器、重传计划、候选对记录、密码学上下文、日志、任务队列，甚至预先触发中继判断。一个很小的探测包可能对应相当大的本地工作量。若仅限制发包速率，却允许未认证会话无限占用内存，资源路径仍然敞开。

有效控制至少要规定候选目的地数量、包数、字节上限、重试间隔、存活时间、并发状态和认证前 CPU 预算。限额还应按注册账户、发现对象、目标地址和目标前缀聚合。数千个会话各自遵守小额度，仍可能把总量集中到同一受害者；单会话合规不是全局安全。

认证之后仍然不能跳过授权。身份正确的对等方也许只获准交换小型控制消息，并不自动获准申请大带宽中继、读取大对象或启动昂贵计算。身份回答“是谁”，授权回答“可以做什么”，资源凭据回答系统实际上投入了多少。

会回应的主机，仍可能不是要找的人

错误投递最容易在目标沉默时暴露；若无关设备恰好回应，情况反而更危险。运营界面可能把套接字建立、STUN 事务完成或连通性检查成功显示成绿色，并把绿色状态继续解释为“对等方可信”。

这些事件首先都是路径观察。即使检查携带凭据，其证明范围也由协议定义。ICE 检查可以表明远端掌握本次 ICE 会话使用的短期凭据，并且某个候选对按协议可用；应用仍需把这个运输结果绑定到自身的高层对等方身份与授权决定。

路径变化也要显式处理。重新提名候选、移动、NAT 重新绑定，或从直连切换为中继，都会改变实际运输路径。应用协议应规定现有认证会话能否继续、是否需要通道绑定或重新认证。若仪表盘在路径已经变化时仍把旧的绿色身份无条件贴在新路径旁边，它展示的是符号连续性，而不是运行证据。

TURN 从另一个方向证明相同边界。直连失败时，中继可能是最可靠、最可控的路径。通过认证的 TURN 分配只证明客户端依照 TURN 规则与中继服务建立了关系；它并不自动识别另一端的应用对等方，也不证明业务数据已经成功到达。中继不等于信任较弱，直连也不等于信任较强。

NAT 不是一种可以贴标签的单一性格

RFC 5128 解释了打洞为何依赖具体行为。端点无关映射允许内部端点向不同远端发送时复用同一个外部映射；端点相关映射则可能针对不同目的地创建不同外部元组，使这种复用假设失效。

映射和过滤必须分开。NAT 可以复用同一映射，同时只接受内部主机此前主动联系过的来源返回流量。因为映射具有端点无关性就把设备称为“开放”，等于把地址分配方式误当作入站许可。RFC 4787 的两套术语之所以重要，正是因为两种属性产生不同路径和不同攻击面。

回环支持也是独立事实。两个对等方可能位于不同下游 NAT 之后，同时共享一个更上游的大型 NAT。它们获取上游公网端点后，可能尝试经由该公网地址相互访问。如果共享 NAT 不支持回环，数据包就不能重新进入内部。候选地址可以真实存在，映射也可以正常建立，直连路径仍会失败。

连接反转只适用于一端拥有公网地址、另一端位于 NAT 后的拓扑。只要双方都能到达中继，转发通常最可靠，但会消耗服务器计算和带宽，也可能增加时延。打洞可以节省这些成本，前提是映射、过滤、时间窗口和拓扑条件同时满足。系统需要记录失败原因，而不是只保留一个“穿越失败”计数器。

端点无关映射还可能让不同会话之间的关联更容易预测。RFC 5128 把它描述为潜在信息通道，并没有证明所有实现都有可利用漏洞，更没有测量当代发生率。正确做法是把可关联性纳入威胁模型，再依据具体实现测量，而不是把可能性写成普遍事故。

地址改写使源 IP 无法承担身份权威

兼容 NAT 的信令必须容忍参与者自认为的地址与外部观察地址不同。正是这种容忍，使路径上的一方有机会替换源地址或尝试登记修改后的地址，把后续流量引到自己所在的位置。

仅认证源 IP 无法干净地解决问题，因为源和目的元组会被改写本来就是机制成立的前提。如果把改写后的元组直接当成身份，就把应用应保留的身份权威交给了路径机制。

RFC 5128 指向更高层身份下的真实应用内容认证，并在需要保密时使用加密。内容交换应绑定参与者身份、会话和必要的运输上下文，使路径替换不能悄然变成对等方替换。加密能够防止中间方读取或修改受保护内容，但可观察的时间和流量仍可能泄露通信关系。

这一分层防御允许基础设施保持克制。协调服务不需要成为全球身份裁判。它要做的是明确自身观察边界，在自己的授权模型下保护注册，保留候选来源，并限制放大能力。应用负责判断对等方身份以及何时释放有意义的资源。

后继协议改善机制，没有抹平证据层级

RFC 5389 把 STUN 重新定位为协议工具，而不是把 NAT 分类成稳定性格的方法。RFC 8445 的 ICE 收集候选、组成候选对、执行带凭据的连通性检查并提名所选路径。RFC 8656 为 TURN 中继分配、许可、通道、认证和过期提供了更完整的规则。RFC 8835 则把 ICE、STUN 与 TURN 放入 WebRTC 运输体系。

这些演进提高了互操作性，却没有把证据链合并。主机候选不同于服务器反射候选；候选对不同于可用候选对；检查成功不同于最终提名；已提名路径不同于应用对等方的长期身份；中继许可不同于执行任意应用工作的授权；路径上出现媒体包也不自动证明预期业务结果。

分层还能纠正对路径的审美偏见。直连可能抵达错误的本地主机；中继可能经过严格认证、限额清晰且易于观察。领导者应按身份、策略、成本、时延、韧性和结果比较路径，而不是把“中间环节少”当成天然优越。

这份记录能证明什么

RFC Editor 与 Datatracker 记录证明 RFC 5128 的发布身份和生命周期。正文证明它记录了当时使用的技术，并明确不是背书。周边 RFC 界定 NAT 行为、STUN、ICE、TURN、UDP 使用与 WebRTC 运输的术语和后续演进。

这些资料不能证明某个当代产品接受任意私网候选，不能说明有多少网络支持回环，不能给出错误主机应答的发生率，也不能测量某一服务的放大倍数或直连与中继的成功比例。证据包没有当前厂商普查、事故流量或用户结果测量。此类判断必须来自运行系统。

这不是分析缺陷，而是决策边界。标准给出机制与预见风险；运行系统必须提供配置、遥测、认证交换、资源账本与结果。用标准引用填补空白的运营单元格，只会让文档权威掩盖现实未知。

资料来源