第二个 VPN 端点：它覆盖什么，不覆盖什么

纸面上看，两个端点就像冗余。实际上，第二个地址只有在客户端能到达它、且它能避开你正在防范的故障时才有用。位于同一条接入线路、同一个账号或同一个目标网络之后的两台服务器，会一起失效。真正有用的问题是：第二个端点消除了哪一个单一故障。

比较两个端点共享的东西

在清点重复项之前，先列出两个端点共同依赖的东西。托管位置、服务商账号、上游线路、DNS 托管、身份来源，以及隧道后端的私有资源，每一项要么是共享依赖，要么是独立依赖。同一区域内的两台虚拟机共享一次服务商故障。同一账号下的两个区域仍然共享计费关系和创建它们的管理平面。

目标网络也值得同样对待。健康的备用网关无法恢复一台离线 NAS，也无法到达上行链路已断的办公网络。如果两个端点都终止在同一个私有子网，第二个只是给一个本来就是唯一故障点的目的地增加了一条路径。

身份是最容易被忘记的依赖。把证书和配置克隆到第二台主机，会造出两个可以复制同一份凭据的地方，而且完全没有说明吊销如何同时到达两边。

第二个端点只有在客户端知道它、并且不用联系支持就能选中它时才有用。OpenVPN 连接配置文件可以携带多条 remote 行并配以选择策略，多数客户端会在菜单里提供备用配置。无论用哪种机制，都要写清你的用户手里是哪一种，因为他们找不到的配置算不上故障切换。

读一读客户端文档中关于会话期间地址变化的说明。有些实现在隧道的整个生命周期内保持原对端，只在重新连接时才考虑备选地址。这一差别决定了死掉的端点是造成短暂中断，还是一条永不恢复的会话。要实测重连路径，而不是假设它会发生。

出口地址改变还会破坏应用状态。故障切换是恢复，把它描述成不中断的连续性，会设定一个传输层无法兑现的预期。

挑一次受控中断并端到端跑一遍，而不是相信设计文档。停掉主端点，然后确认被授权的客户端能通过备用路径到达目标应用，而未获授权的客户端仍然到不了。记录切换用了多久，以及应用看到了什么。

dig +short vpn2.example.net
ip route get 10.20.30.41
journalctl -u openvpn@backup --since '-10 min'

第一条命令在你还不需要它的时候，确认备用名称能解析到可路由的东西，这是这里最便宜的测试。第二条显示备用路径起来后，内核会为某个私有目的地使用哪个接口。第三条给出客户端日志，写明它实际连上的对端，这是切换真正发生的唯一凭据。也要留意切换间隙的阻断行为，因为切换期间放行流量的策略比短暂中断更糟。

然后把原来的端点放回来，确认客户端是否回切。偶然发生的回切，是没人规划过的行为。

用一段话总结覆盖范围：第二个端点消除了哪类故障，它和第一个共享哪些故障，以及切换依赖哪些前提。写明客户端侧机制，以及在两处都必须存在的私有路由和 DNS 行为。公网出口不能替代私有网关，而把它们当成可互换的文档是会被人相信的。把你做过的恢复测试附上，注明日期和结果。

独立于一台服务器，不等于独立于共享账号或目标网络。正是把这句说出口的那一段，才能阻止第二个地址在内部被当成高可用来卖。它也会告诉下一位运维人员：当这对端点一起失效时，先查什么。