VPN 故障切换：当返回路径仍留在旧隧道上

备用隧道建立起来，主隧道断开，而应用仍然超时。两个站点的隧道状态看起来都正常，这正是令人困惑的地方。只把请求切到备用、却让响应留在旧路径上的，不能算故障切换。下面的手册测试的是返回路径，而不只是握手。

先记录两端的路由；只从一个站点看，无法发现非对称路径。这也是时间紧张时最常被跳过的一步。

测试前记录两个站点的路由

对每个受保护的网段，写下主路由、备用路由以及两者之间的优选方式。把每个 VPN 端点后面的 LAN 网关也写进去，因为端点很少是最后一跳。

静态度量、被跟踪的路由和动态路由表达可用性的方式各不相同。弄清楚你的设计用的是哪一种，以及备用路径需要什么条件才会生效。把条件写在路由旁边，例如在探测失败之前使用更低的度量。

在两个站点都这样做。一侧优先、另一侧被忽略的备用路径，产生的正是你想避免的非对称。

在每个阶段观察请求与响应

用一个无害且被允许的应用，观察三个阶段：正常、主路径故障和恢复。每个阶段都记录哪条隧道承载请求、哪条承载响应。能 ping 通对端地址，并不能证明受保护的应用路径可用。在两个站点都记录，才能看清单向流量。

如果请求移动了而响应没有，检查远端站点到客户端网段的路由，以及它对备用路径的优先级。这是路由决策，而不是隧道故障。

测试后恢复原来的条件，并确认主路径重新被优先选择。恢复后仍未被优先选择的主路径，说明故障切换设计还没完成。

网关变化时处理会话状态

防火墙和 NAT 可能把连接状态保存在某一台网关上，而切换到另一台网关的路径不会带走这些状态。有些应用会自行重连；另一些则要等到会话重建才恢复。如果备用路径改变了公网源地址或转换后的私网地址，远程访问规则也可能随之变化。把任何预期的会话重启写进文档，而不是承诺无缝切换。

在应用需要的地方保持地址稳定。让每个会话都改变源地址的故障切换设计是一种设计选择，应当写下来。这个选择决定了用户实际会注意到多少中断。

测试一个保持长连接的应用，而不只是新请求。

恢复主路径并检查抖动

确认路由通告或优先级稳定下来而不振荡。抖动的主路径可能比明确的中断更麻烦，因为每次切换都会重置状态。

让网关管理可以通过恢复路径访问，以免测试本身把你关在门外。记录阶段、观察到的路径和恢复时间；正是这份记录让下一次切换可预期。strongSwan 关于转发的说明 在端点是 Linux 主机时很有用。