为什么每次密钥轮换时 VPN 都会掉线

连接能撑一小时然后就断，客户端除了 disconnected 之外什么有用的都不报。问题恰恰出在那个周期上，因为续期交换里有东西与首次握手不同。定时器只决定你何时撞上它。要保存那次交换的消息，而不是最后那句标签。

读阶段，而不是读标签

在 IKEv2 里，IKE 关联和 CHILD 关联按不同的节奏续期。第一次协商能接受的提案，第二次并不自动能接受。一边可能完成而另一边被拒绝，于是隧道只存在一半。用拥有这次交换的工具去抓，而不是看客户端日志的一行：

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

对 OpenVPN 来说，对应事件是由版本和部署设置支配的重协商。它的认证行为有自己的失败模式。真正重要的消息会点名失败的阶段，你应当逐字记录，而不是在工单里转述。

也把时间戳记下来。在最后一次成功协商之后按固定间隔掉线，与使用中随机掉线是完全不同的发现，而这个间隔往往是唯一留下的证据。

对比失败的那个提案

被拒绝的提案会在应答端给出明确消息。常见原因是两端在算法、密钥长度、组或生存期上存在差异。最初的 CHILD 协商可能成功，是因为由对端发起，也就是用了对端的提案列表。改动之前先看两端。

生存期不一致值得特别关注，因为一端看起来很宽裕的取值，可能让另一端发起一次它无法完成的续期。密钥更新行为文档描述了关联续期如何被触发，以及两端在时间预期上可能如何不同。要比对两端各自声称支持什么，而不是配置文件暗示了什么。

旧配置文件或供应商模板可能钉住一个当前版本不再提供的提案。只有强制发起新一轮协商时，这种不一致才会暴露。

把凭据问题与对端不可达分开

续期时认证失败，在客户端看起来相似，在服务端却完全不同。如果重新协商时会重新核对凭据，那么过期证书、被吊销的账户或改过的密码，会在正好到达续期间隔时掉线，而此前每次连接都成功。对端不可达是第三种可能，它完全不产生拒绝：包发出去了，没有任何回应。那种情况通常跟着网络变化走而不是定时器，所以要查失败是否出现在漫游、空闲时段或路由变化之后。

按远端记录下来的内容区分这三种情况。带原因的拒绝、认证失败和沉默是三种不同的修法。重启客户端会把它们压成一条没用处的观察。

在怪网络之前，先核对证书日期和账户状态。两者都好查，而且两者在客户端自己的消息里都看不见。

强制触发一次续期并读结果

用运营商支持的方法强制触发一次续期，而不是等一小时后的下一次。做的时候要保持所需的失败策略不变。关掉校验或把生存期拉长到一天，只会让症状从日志里消失，并没有修正任何东西。它还会给下一个人留下更长的中断。

修好之后先检查续期后的隧道，再从应用里发一个新请求。关联更换时还活着的应用会话，可能需要在隧道恢复健康后自行恢复。用户会把这报成 VPN 仍然坏着。

记录发布版本、协商出的定时器以及失败的阶段。这样下次复发就能与这一次对比，而不是再凭记忆描述一遍。