多路径 VPN：运营商必须提供的四项保证

加一条 WAN 链路，隧道是起来了，可只要有一条路径抖动，文件复制照样卡住。链路健康、VPN 进程也在跑；缺的是运营商与隧道之间的契约。几个套接字不会自动表现得像一条连接，上面的应用在交付中断之前看不出差别。契约的每一部分都对应一种可测试的故障，这正是它有用的原因。

在选型之前先把这份契约写下来。它包含四部分：VPN 收到的流、运营商如何恢复丢失的数据、哪一端点身份在路径切换后依然成立，以及整条路径失效时整体如何表现。

症状：链路是通的，会话照样断

监控图显示两条链路都在线，只能证明每条路径都能承载流量。它不能证明 VPN 看到的是一条有序的流，不能证明一条路径上丢失的包会在另一条上恢复，也不能证明对端还知道自己正在和哪个会话通信。契约的其余部分覆盖了这张图看不到的东西。

传输卡住时，先弄清楚运营商是否在存活路径上继续交付。如果第二条链路空闲时会话死亡，说明运营商从未用过它。如果会话存活但数据乱序或重复到达，说明运营商在没有连接级契约的情况下搬运数据包。两边的时戳通常能把这一点说清楚。

这个区别决定了怎么修。路由或策略问题需要改变路径选择；缺少排序与恢复层则需要另一种传输，而不是更大的缓冲区。

如果 VPN 需要可靠的有序字节流，运营商必须在单条路径之上标识字节区间。底层每条 TCP 连接只给自己的段编号，接收方无法仅凭这些编号跨路径重排。

Multipath TCP 是标准化范例。它在协调多条 TCP 子流的同时呈现一条可靠的字节流，具备数据级序号映射与确认。应用读到的是流，而不是碰巧最先送达某段的那条子流。

在 Linux 上，MPTCP 按套接字通过 IPPROTO_MPTCP 选择性启用。当协商无法使用多路径行为时，有文档记载的回退是普通 TCP，这意味着应用可能一直只在一条路径上工作，从未用到第二条。要检查已部署套接字实际协商出的行为，而不是假定内核设置已经生效。

延迟和丢包率不同的路径迫使运营商进行缓冲、重排和重传。契约必须写明允许多少缓冲、应用看到什么背压，以及由哪条路径承载重传。

保持连接却停止交付的路径，比正常关闭更难处理。运营商必须检测到它、迁移未完成的数据，并避免无限等待一个永远不会到达的段。简单的“两条链路都在线”检查覆盖不了这种状态。

重复需要自己的规则。在两条路径上发送同一份载荷可以改善时延，但接收方必须在副本到达 VPN 之前将其抑制。IPsec 的重放保护按安全关联可选，并会检查序号；一个重排或重放数据包的重复层可能触发它，也可能把问题藏到隧道断开为止。

当新路径出现时，对端需要一种稳定的方式识别会话。如果每条路径都作为独立隧道认证，VPN 可能看到两个会话而不是一个。如果运营商把路径汇聚到一个会话之下，就必须定义新路径如何认证，以及旧路径会怎样。

记录哪些地址和标识保持稳定：隧道端点、运营商会话标识，以及中间的任何代理。即使代理从来看不到受保护的载荷，它也增加了另一层可用性与信任边界。

策略也在这里。一条来自意外网络的路径可能在技术上有效，却仍然违反预期的信任模型。要决定新路径是自动接受、要求认证，还是直接拒绝。

要测试一整条路径失效，而不只是变慢。存活路径应当在不出现无界内存增长的情况下承载会话，恢复也不应依赖比应用所能容忍的更长的定时器。失效路径恢复后，运营商必须决定是重新均衡，还是让流留在原处。

为缓冲、重传和路径数量设定上限，然后在丢包、乱序、重复和延迟失衡的条件下验证。聚合带宽在这里是最不重要的数字；交付连续性和内存边界才是契约。

把运营商的恢复状态与 VPN 的密码状态分开。用自制的可靠性层替代既有的认证或加密并不是捷径，跨层复用序号正是重放防护和诊断变得不可靠的原因。

把四项保证写成通过或不通过的检查：一条有序流、明确的恢复、稳定的会话身份、有界的故障行为。每项检查都在一条路径降级、然后再移除一条路径的条件下运行。

一次跨路径切换成功的文件传输，并不能证明持续运行。在切换首选路径的同时重复传输，并同时检查运营商的视角和 VPN 自己的计数器。如果两者对哪条路径承载了数据说法不一，契约就还不具备可观测性。

把签字确认的矩阵与部署放在一起。它告诉下一位工程师承诺了什么行为、测试了哪些路径组合、哪种故障模式仍不受支持，不必再对着链路状态灯猜一轮。