摘要

  • 10 月 1 日发布的 IPSECME 工作组 Internet-Draft 第 08 版，把 NAT 场景中的触发条件明确为：一条来源 IP 和／或端口不同的新 TCP 连接收到了受保护的 IKE 消息。该连接只能用于 IKE 安全关联，不得改变其下任何 ESP 子安全关联的来源地址或端口。
  • 同版还把双向流量预期下“没有收到 ESP 包”列为可能存在可达性问题的线索，同时保留加密 ESP ping 作为另一种检查办法。没有入站包不是故障定论；IKE 握手成功也不是 ESP 到达的证据。

一条 VPN 隧道在控制台里显示协商成功，应用数据却过不去，这并非自相矛盾。IKEv2 负责协商和维护安全关联，ESP 承载被保护的数据包。该草案允许两者走不同传输方式：体积较大的 IKE 交换可借助 TCP，而 ESP 在条件允许时仍走原生 IP 或 UDP 封装。这样避免为了控制报文而把数据流也强行放入 TCP，却要求运营者分别观察两条路径。中间设备对 TCP、UDP 和 IP 的放行、映射与超时可以不同。

第 08 版真正新增的精度，在 NAT 小节的一个条件句。第 07 版只说从新来源地址或端口收到受保护的 IKE 消息；新版限定它来自新建的 TCP 连接，且来源 IP 和／或端口发生变化。未位于 NAT 后方的一端应只将这条连接用于 IKE 安全关联，不能借机改动其子 ESP 关联记录的来源 IP、端口。相反，来自新来源且完整性验证通过的 ESP 包，有独立的 ESP 端点更新规则。两种证据分别影响各自的状态，不能互相代替。

“IKE 与 ESP 分路”并非这次修订才提出。早先版本已设计 SEPARATE_TRANSPORTS 通知：发起方可先在 UDP 4500 上进行 IKE_SA_INIT，若响应方回送通知，再把后续 IKE 交换切到 TCP；初始交换本身很大时也可直接从 TCP 开始。分路协商成功后，ESP 尽可能走 IP 或 UDP。若从 TCP 开始而响应方没有回送通知，草案规定 IKE 与 ESP 均按既有 RFC 9329 方式走 TCP。把这些原有模式说成第 08 版新设，反而会遮蔽这次对状态更新边界的修正。

新版的另一处文字变化是故障信号。若业务本来就应双向通信，迟迟没有入站 ESP 包，可能提示 ESP 路径不通；加密 ESP ping 仍可用于显式检查。但沉默也可能出自业务空闲、策略允许单向流量或监测点位置不对。草案没有说可以仅凭沉默断定防火墙、NAT 或攻击造成故障，更没有给出具体产品事故。

更广的运作规则此前已存在：IKE 的 TCP 连接不会替 ESP 的 UDP 路径维持 NAT 映射，数据路径需自己的 keepalive；如果 IKE 一开始就在 TCP 上完成交换，也没有隐含证据表明 ESP 可达。子安全关联建立后，除非已有其他证据，发起方应核验 ESP 路径；若无法确认，就必须删除现有 IKE 关联，在 TCP 上重新建立且不再提议独立 ESP 传输。这是对数据路径核验结果的回退，而不是把“控制连接正常”误读为“整条隧道正常”。

Datatracker 将该文件列为活跃工作组草案，已提交出版请求；它还不是 RFC，文中通知码仍待分配。可核实的新闻事实，是新 TCP 连接的限定语和更谨慎的 ESP 观测信号，而非已经发生的部署或故障。

来源