VPN 会话计时器与认证令牌分别到期

VPN 掉线可能来自从客户端看完全相同、底层却毫无共同点的原因：隧道会话结束、空闲计时器触发，或者客户端重复使用的凭证已经过期。每个原因有不同的负责人和不同的修法。掉线瞬间的错误序列正是区分它们的依据，而且通常只有一行。

一条隧道上跑着三个时钟，而其中只有一个才是隧道本身。

一条隧道上的三个不同时钟

会话时钟属于网关：最大连接时长、空闲超时，或者两者兼有；达到其中任何一个，它就会终止隧道。令牌时钟属于认证系统，它决定凭证在不需人工介入的情况下可以再次出示多久。路径时钟属于客户端与网关之间的任何 NAT 或防火墙，它会让自己认为已结束的流对应的映射过期。三者都会造成断连，但没有一个会给出同一行日志。

只有第一个才是 VPN 的概念。另外两个借自身份与网络领域，却常被当成同一件事。

令牌实际上是如何被重复使用的

OpenVPN 服务器可以在首次登录后签发认证令牌，因此控制通道重新协商时不会再次向用户索取凭证。客户端持续出示该令牌，服务器决定它还能被接受多久。当令牌寿命短于重新协商间隔时，下一次重新协商就会失败，客户端报告的是认证错误而不是超时。同一个配置文件能用一小时、随后在固定时间点失败，原因就在这里。

重新协商间隔是另一项设置。改它只会移动令牌出示的时点，并不改变令牌的寿命。

从客户端看，每种到期分别是什么样子

会话超时通常表现为一次干净的断开，并带有服务器侧的原因，往往发生在可预测的时长之后，且不附带认证错误。空闲超时看起来像沉默：隧道不再承载流量，随后保活机制放弃。令牌到期则表现为 AUTH_FAILED，发生在一秒前还正常的会话中途。

先读那一行，再看时钟。与配置值吻合的时长并不是巧合。

为什么保存的密码帮不上忙

缓存的密码只回答针对密码的挑战。它不会延长令牌寿命，也无法满足第二因素或设备状态检查的挑战。提高重试频率、缩短连接超时或重新导入配置文件，都不会改变身份系统接受该凭证的时长。

持久的修法是在正确的对象上设置正确的寿命，或者采用一条能在无人介入下完成所需挑战的客户端流程。

需要记录并测试什么

把三个值都写下来：网关的会话与空闲上限、令牌寿命，以及路径上与本次问题相关的最短映射超时。然后逐个故意测试到期：缩短其中一个值、观察客户端报告什么，再恢复原值。确认每个边界上用户必须做什么，因为要求每小时完整登录一次，是某人应当有意做出的策略决定。

完全没有认证事件就发生的掉线，属于路径或空闲计时器，那是另一项调查，证据也不同。