pfSense 上三种 OpenVPN 故障切换，三套机制

pfSense 上的「OpenVPN 故障切换」至少涵盖三种互不相关的设计，每一种都需要不同机制。在备用互联网链路上保持隧道存活、重新连接到另一台服务器、以及把 LAN 流量导入另一条已建立的隧道，并不是同一个功能的不同变体。在构建网关组之前，先想清你要防的是哪种故障。解决其中一种的网关组，对另外两种毫无作用。

先写清故障，再建组

写下你希望在故障期间成立的那句话。「隧道通过备用 WAN 重连」和「分支仍通过另一条隧道访问应用」是两句不同的话。只有第一句讲的是传输层。

然后把它对应到一种机制。本地 WAN 断线是接口选择问题，远端端点失效是连接列表问题，而已经建立的隧道内部路径不可用，则是路由和策略问题。

本地 WAN：搬移传输

对 pfSense 的 OpenVPN 客户端来说，受支持的多 WAN 方案会选定一个合适的网关组，作为客户端绑定的接口。正是这一点让外层连接在主链路故障时改走备用链路。它本身并不改变内层流量如何路由。

同一设计的服务器侧是另一件事。一个需要被多个公网地址访问的 OpenVPN 服务器，要为每个入口都准备监听和入站策略，而不只是准备一个能从两条链路拨出的客户端。一个可用的公网入口，并不能证明第二个入口已经配置好。

针对转发 LAN 包的一条策略路由规则，并不是把本地生成的 VPN 传输连接搬走的那个设置。这是两次不同的查表，改其中一个不会改另一个。

远端端点：换一台服务器

备用远端是连接列表的功能。当前条目不应答时，客户端会尝试下一条，这在某一台具体主机宕机时有用，而在你自己的上行链路故障时没用。两种故障在用户桌面看来很像，却需要不同的修法。

每个候选都必须是真正的替代：兼容的认证、兼容的客户端策略，以及对同一批私有资源的访问权。第二个主机名如果解析到同一套已经失效的基础设施，那不算备份。缺少所需路由的服务器也不算，无论它的握手看起来多么健康。

这套机制也不会让两条隧道同时转发。它是一条接一条地替换连接，而两者之间的空档对正在运行的一切都是可见的。

隧道路径：另选出口

当两条隧道都已建立、而你想让流量走更健康的那条，机制就是分配好的 VPN 接口配上它自己的网关，再加一条明确的策略规则，把正确的流量送过去。在这些已分配接口之上再建网关组，可以表达优先级和监控。

这个设计讲的是选择，不是恢复。把新连接搬到第二条隧道，对第一条上已经建立的会话什么也没说，对方是否接受新的源地址也没说。把它当成恢复机制，就是期望值定得太高的开始。

如果要求是现有会话必须存活，就把它明确写出来。大多数实现不会在隧道之间迁移一条活动流，而按「会迁移」去设计，得到的切换在图上正确，实际却会掉光每一条打开的连接。

监控、NAT 与失效关闭规则

监控应该测试隧道本该交付的东西。一个从隧道对端能应答、但从其后应用网络不能应答的目标，会在用户什么也看不到时报健康。一个不可达的诊断目标，会在路径正常时报死亡。要有意识地选地址，并确认它只能通过预期的那条隧道到达。

检查两条出口的源 NAT。主链路上正常的转换，并不描述备用的源地址，而远端私有网络需要一条与所呈现源地址相匹配的回程路由。在一条路径上正确的转换，在另一条上可能悄悄出错。

然后决定，对于 绝不能使用 WAN 的流量，会发生什么。pfSense 对所选网关失效的规则有既定行为，而后面一条宽泛的放行规则或默认路由可能推翻你的意图。把被阻断的结果写成需求，再把路径拆掉来验证。

分别测试丢失与恢复，用你有权生成的流量，并同时观察三件事：承载外层连接的 WAN、承载应用请求的隧道，以及应答所走的路径。一对绿色的网关指示灯并不在这三件事里。 Netgate 的多 WAN 指南 描述了本文依赖的传输绑定与导出的客户端备选。