两个IPsec网关，没有共享IP：故障切换到底做了什么

会议进行中关掉网关A，一分钟后隧道经由B恢复；连接可用，视频通话未必。这就是两台独立编址的IPsec网关之间冷切换的真实面貌。客户端重新选择一个端点并建立新关系，从而在不转移旧会话加密状态的前提下恢复可达性。走一遍流程，哪些承诺能兑现就一目了然。

铺设场景：两个地址，没有浮动IP

网关A在一个可达地址上应答，网关B在另一个地址上应答。客户端有获准的方式在A消失时选择B，而且不存在两台网关都声明的共享外部地址。在这个设计里，虚拟IP指的是那个共享入口，而不是分配给远程访问客户端的内网地址。

这个定义很重要，因为两种概念在工单里常被混为一谈，而两者的修法并不相同。报告说共享入口没有跟随网关，描述的是一种设计。报告说笔记本电脑丢失了内网地址，描述的是客户端的租约。不同的责任人，不同的日志，不同的修复。

走过故障：先检测，再重选

首先，某个机制发现A不再应答。这可能是隧道层的对端死亡检测、路由协议撤销路径，或最终迫使重连的应用超时。三者的时间尺度不同，最慢的那个通常决定用户要等多久。

然后客户端通过部署支持的机制选择B：第二个已配置的远端、解析到健康地址的DNS名称，或改为偏好另一条路径的路由。选择是一个策略步骤，必须在故障之前就存在，否则它只会偶然发生。

B能继承什么，不能继承什么

B可以与A共享配置模板、证书颁发机构和认证策略。它无法继承活动中的安全关联。会话密钥、安全参数索引和序列状态属于A与客户端建立的那段关系，B一样都没有。

在网关之间搬移这些状态是真正的工程问题，因此strongSwan的高可用文档把它当作集群设计，而非一个配置开关。某个集群配方并不是云网络的通用答案，缺少配套基础设施地照搬，买到的是复杂度而不是连续性。

建立一段新关系

选定B后，客户端执行新的IKE交换：新的nonce、新的Diffie-Hellman值、为结果关联生成的新标识符。认证在B上重新进行。如果设计依赖机器凭证，重连可以无人值守；如果要求人的因素，就必须有人在场，故障切换才能完成。

要在故障之前定义这段用户体验，而不是在故障之中。明确说清客户端会做什么、会尝试多久、放弃时显示什么，因为一分钟的重连和一次支持电话之间的差别，通常就是文档和经过测试的配置。

保留同一内网地址对期待稳定本地标识的应用有帮助，但并不能保住它们的会话。NAT绑定会过期，TCP连接会重置，任何带自身超时的东西都会独立决定是否重试。

并行两条隧道是另一种设计

当两台网关和路由设计都支持时，同时运行两条隧道是一种有效模式。此时路由选择决定活动路径，回程也必须一致，否则流量从一个网关出去、从另一个网关回来，却没有状态与之匹配。

重叠的隧道策略本身不会形成有序的故障切换。它们制造两个候选，必须有某种东西确定性地在两者之间做决定，无论是路由度量、策略优先级，还是客户端中的显式偏好。

无论选择哪种形态，都把约定写下来：故障如何检测、备选如何选择、备选要求什么认证、重连预计要多久。共享IP可以简化发现，但它不是持续状态的同义词，可用性无论如何都是一项设计。