轮换 AWS VPN 的 PSK：哪条隧道会断，何时断

两端对预共享密钥不一致的那一刻，隧道就会中断，并且会一直保持断开，直到双方都持有新值。这部分是意料之中的：AWS 把这次变更视为所选隧道的中断，而密钥不一致期间对端不会完成 IKE。让人意外的是后半部分。另一条隧道不会自行承接流量，除非你已经验证它能承载。按这个顺序轮换，中断就只会停留在一个隧道内。

密钥变更时实际会发生什么

ModifyVpnTunnelOptions 会重写一条隧道的选项，该隧道由其外部 IP 地址标识。隧道会被拆除并重建，因此 IKE 和 IPsec 会用新密钥从头协商。AWS 指出中断可能持续数分钟，足以让路由协议察觉。同一连接中的另一条隧道不受这次调用影响。

发送任何内容之前，还有一个值得了解的副作用。修改操作接收完整的隧道选项集合，因此你省略的字段会被以默认值写回。如果你曾调整过第 1 阶段或第 2 阶段的生命周期，或对端失效检测设置，请在同一请求中传入当前值，或者计划事后恢复。

先读取当前值，再只改一个字段。这个顺序就是这项工作的全部纪律。

先把 AWS 隧道与正确的对端对应起来

控制台按顺序给隧道打标签，而你的设备并不使用那个标签。要通过外部 IP 地址识别隧道，并与客户网关上的对端配置段对应。本地配置里的隧道 1 并不能证明你正在编辑 AWS 称为隧道 1 的那条隧道。

从连接本身开始，它会列出两条隧道以及各自当前持有的密钥：

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

返回的密钥就是当前正在使用的那一个。在改动任何东西之前先与对端配置比较，因为已经存在的不一致正好解释了某条隧道为何从未稳定过。

先让另一条隧道承载流量

一条连接里有两条隧道，并不证明你的设备配置了两条、两条都宣告了你需要的前缀，或者流量会在两者之间转移。要检查备用隧道的协商、它的路由，以及双向的真实应用流量。使用 BGP 时，活跃的邻居关系是有用证据，但不等同于确认前缀。使用静态路由时，要确认网关如何选择路径，以及首选路径消失时它会怎么做。

如果备用隧道无法承载工作负载，就在改动密钥之前安排中断窗口，或者先修好备用隧道。控制台页面上的状态灯并不等于服务不中断的承诺。

轮换一条隧道，然后用真实流量验证

备用路径得到验证后，流程很短。记录隧道地址、它的对端以及非机密设置，并保留一条不依赖你即将切断的那条隧道的管理通道。

1. 为选定的外部地址更新客户网关对端，或者把变更准备好，让它在 API 调用后几秒内生效。
2. 发送修改调用，带上新密钥以及当前的生命周期和 DPD 值。
3. 等待 IKE 和 IPsec 恢复，然后确认路由和所需前缀。
4. 让一条有代表性的应用流量经过该隧道，并观察双向。

两端不一致期间以及 AWS 应用修改期间，隧道都不可用，因此对端更新必须紧接着进行，而不是等到午饭后。只有当变更后的隧道承载真实流量时，才应在另一条隧道上重复该流程。

如果第一条隧道之后恢复或路由仍不确定，就停下来。两条半好不坏的隧道比一条你确认可用的隧道更糟。

恢复停滞时，去读 IKE 一侧

两端都持有新密钥后仍然断开的隧道，通常是轮换暴露出来而非造成的策略不一致。提议、对端发送的身份以及流量选择器都必须与 AWS 一侧一致，而一个曾经在已建立隧道中存活的取值，在新的协商中仍可能被拒绝。在第二次更改密钥之前，先读协商状态以及附带的消息。

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

如果需要回滚，不要仅仅因为旧密钥以前能用就恢复它。把已泄露的密钥当作已泄露处理，转而修复协商。最后确认两条隧道，并更新密钥清单，让每个对端记录自己持有哪个值，同时把 AWS 隧道选项文档放在运行手册旁边。