如何在路由器上构建不泄漏的 VPN 故障切换策略

故障切换完全按配置执行，而这正是问题所在。主隧道断开时，路由器把默认路由切到有线调制解调器，笔记本电脑照常上网，也没有人打电话。两天后有人发现，财务共享目录已经在开放的互联网路径上暴露了六个小时。路由器上的 VPN 故障切换策略不是路由技巧；它是对首选路径消失后流量该怎么办的决定，而这个决定必须在路径消失之前就存在。

先决定结果，再挑检测器

通常桌面上有三个结果：让受影响的客户端走备用隧道、让它们使用普通 WAN，或者直接阻断。写下哪一条适用于哪个 VLAN、SSID 或设备类别。正是那条单一的「切换到 WAN」规则，让上面的财务共享目录走上了公网路径。

这三者不能互换。回落到 WAN 能让服务台继续接电话，却把内部名称暴露给本地解析器。备用隧道保住了策略，但可能落在对端不接受的出口地址上。阻断对工资 VLAN 是正确的，对从未用过隧道的访客网络则是错误的。

让检测器对准你真正担心的故障

握手状态、接口状态和可用的转发是三种不同的信号，而用户只关心最后一种。WireGuard 对端可以显示刚刚完成握手，同时运营商上游正在丢包。一个 OpenVPN 客户端可以在它推送的路由已经无法解析之后，仍然停留在「已连接」。

在 pfSense 上，实用的做法是由 dpinger 喂给一个网关组：它探测监控地址，在丢包或延迟超过阈值时把网关标记为不可用。把这个监控指向隧道之外的东西，比如远端 LAN 里的一台主机，或者经由隧道可达的公网地址。把目标设成隧道自己的对端地址，测到的只是你早就知道还活着的那一段。

把网关组建成让备用始终是最后手段

用分层而不是一张扁平的成员列表。主用放在第 1 层，备用隧道放在第 2 层，WAN 放在第 3 层，且只给策略允许的 VLAN 使用。在 pfSense 里这一项位于 System > Routing > Gateway Groups：把两个网关都加进去，给它们不同的层级，把 Trigger Level 设为成员失效加丢包，保存，然后把该组应用为接口默认网关，或填进需要它的防火墙规则的 Gateway 字段。

对于 pfSense 2.5 及以后版本上的 OpenVPN 客户端实例，实例的 Default Gateway 设置决定隧道是否替换系统默认路由。只有当你假设存在的那条路由确实已经安装时，按规则做的策略路由才会按你预期的方式工作。更改后请查看 Status > Gateways，而不是相信隧道的状态图标。

两个设置造成了大部分抖动。一个是探测间隔比运营商自身的重新收敛还短。另一个是主用和备用共处一层的网关组，于是两者始终都符合条件。在用户替你先感受到切换之前，用丢包和延迟阈值加上迟滞。

关掉隧道从未掌控过的路径

首先是 DNS 泄漏。解析器继续在 WAN 上应答并从 WAN 转发出去，于是流量虽然被钉在隧道里，名称仍然经运营商解析。限制解析器的出站接口，把内部解析器推给客户端，并在只用 VPN 的 VLAN 上对其它一切阻断 53 端口。

IPv6 需要自己的决定。双栈 LAN 可能丢掉隧道却保留一条可用的全局 IPv6 默认路由，于是浏览器偏好 IPv6 并从 WAN 离开，而 IPv4 看起来被管得严严实实。要么把 IPv6 路由进隧道，要么在隧道断开时停止通告全局前缀。半套策略比完全没有更糟，因为它看起来像是有效的。

然后是回程路径。如果备用出口使用不同的源地址，对端必须知道如何把流量送回这个地址，而所有以旧地址为键的状态都已经死了。主隧道断开时已经打开的会话不会迁移；它们会一直停到超时，然后由应用决定怎么办。

测试断开、抖动和重新进入的路径

在有无害流量运行时拔掉主隧道，然后读四样东西：用 Status > Gateways 看组的成员状态，用 pfctl -ss 看仍然钉在旧网关上的状态，从客户端做一次 traceroute 看出口路径，再查一次解析器看是哪台服务器应答的。

现在让它抖起来。把主隧道接通三十秒、断开三十秒，做两轮。如果流量追着每一次切换跑，说明阈值太紧或者分层错了。按你自己的时间表修好它，否则运营商会按他们的时间表替你修。

最后，确认你仍然能管理这台路由器。保留一条带外路径，比如控制台线缆、管理 VLAN 或蜂窝调制解调器。把你锁在外面的故障切换测试，是你无法完成的测试；而一台够不着的路由器也无法自己切回来。

在宣布策略完成之前，你应该不用打开终端就能回答四个问题：隧道断开时哪些 VLAN 可以使用 WAN，检测器在监视什么、等多久，哪些名称服务器和 IPv6 路由会随路径一起移动，以及备用也失效时你怎么回去。如果任何一个答案是「默认是什么就是什么」，这套策略仍然属于路由器，而不属于你。