浮动 VPN 备份路由不接管：故障切换检查清单

浮动静态路由等待的是资格，不是数据包停机。围绕探测路径、阈值与回切的六项有序检查。

你的浮动 VPN 路由已经配置好，备份距离大于主路由，但它从来不动。或者它动了一下，几分钟后又切回来，而无线链路仍然中断。这两种情况下，决定路由资格的都是你关心的故障之外的东西。

按顺序执行这些检查。每项都有停止条件，前面的检查失败，后面的检查也救不回来。示例使用 RouterOS 语法，因为距离、网关可达性和递归下一跳在那里都能在配置里看到，但顺序适用于任何使用被跟踪静态路由的路由器。

给备份要覆盖的故障命名

「主路由挂了」是四种不同的观察。丢失对端的无线链路、丢失载波的接口、不再应答的远端网关，以及停止工作的应用，从路由器的位置看去都不一样。在任何人改动距离值之前，先写下设计针对的是哪一种。

然后检查独立性。如果 VPN 的外层传输走同一条无线路径，或者走共享同一上游的接入链路，那么备份就不是第二个故障域，会在你最需要它的时候恰好断掉。在纸上拔掉主链路：如果隧道自身的传输也随之死亡，浮动路由只覆盖配置错误，覆盖不了真正的故障。

不要再让距离去探测任何东西

更大的距离只是让路由更不被优先。这就是它的全部职责。只要主静态路由仍然有资格，浮动路由就保持不活动，这是正确行为而不是缺陷。只有主路由被撤销或被标记为不可达时，故障才会显现。

对静态路由来说，这需要一个显式的跟踪器：

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

读懂它在测什么：下一跳，而不是目的地。一个在本地侧仍然应答、但向前的转发已经坏掉的无线链路，会让主路由保持活动。这就是静默故障，距离加网关检查抓不到它。如果这种情况重要，检测就必须来自能观察远端的东西：路由协议的邻接关系，或者你自己定义了路径与结果规则的探测。

追踪探测自身的数据包去了哪里

健康探测自己也有路由。一旦数据流量切到 VPN，一条没有约束的、发往同一远端地址的探测可能跟着它走、成功返回，并被读成主路由已恢复的证据。流量回到坏路径上，循环就重复了。

把探测钉在它本该判断的路径上。在 RouterOS 里通常的做法是经主网关指向监控目标的主机路由，作用域小到没有别的路由能解析它，RouterOS 手册里的递归故障切换示例构建的正是这一点。要在备份处于活动状态时到实时表里确认，而不是看配置注释：

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

在添加目标之前，先定义探测结果意味着什么

一个拒绝 ICMP 或进入维护的目标看起来和路径故障一模一样，而三个没有规则的目标只会给你三种意见。先定规则再实现：例如，三个目标中有两个连续两个间隔失败，就判定主路由不可用，并写进值班的人能找到的运行手册里。

把失败与恢复的阈值设成让一个丢包不会搬动整个站点。迟滞会多花一点检测时间，换回稳定性。间隔要按故障能容忍多久来选，而不是按探测能跑多快来选；回切要比切换更慢，好让主路由必须先证明自己，才能拿回流量。

检查回程路径与会话叙事

只在一个方向上生效的切换只是半个设计。远端站点需要一条经 VPN 回到你源网段的路由，否则回程流量会从意料之外的地址到达，撞上已经对不上的防火墙状态。即使新连接可用，已有会话也会断，所以把这一点写进验收标准，而不是承诺传输不会中断。

把管理访问留在被测试路径之外。如果你唯一的入口是主路由，切换测试会把你锁在行为异常的设备之外。

执行验收序列

三个测试覆盖大部分情况：主路由物理丢失、接口仍然在位的静默转发故障，以及主路由恢复。对每一项，记录探测的源与下一跳、活动的目的路由，以及两个方向上新鲜的、被放行的应用交互。

区分设计优劣的正是静默故障。如果备份在那里不接管，你造的是链路监视器，而不是路径监视器。判断这是否可接受，并把限制写在值班工程师会读到的地方。第二条已连接的隧道本身并不是一套完整的备份策略。

相关文章