VPN 重连时为何再次要求凭据

一个运行了数小时的隧道，在笔记本唤醒的瞬间要求输入密码，而配置里没有任何改动。真正改变的是重连试图复用的那份凭据的状态。支配这一点的是三类材料，只有其中一类能熬过任意长度的间隔。

先读清客户端索取的是哪一类，因为三者的过期时钟不同，失败时的提示也不一样。

三类可复用材料

缓存密码是客户端持有的秘密，在账户修改它之前一直有效。会话令牌由服务器在登录成功后签发，带有自己的生存期，随时可以被吊销。TLS 会话票据或 IKE 安全关联属于协议状态，续接成本低，与你的密码完全无关。三者由不同组件签发，也各自按自己的条件过期。

第一类能熬过重启，第二类通常能熬过休眠，第三类可能完全熬不过一次网络切换。把它们混为一谈会得出错误的处置，例如去重置一个从未被拒绝的密码。

提示本身就是诊断。出现浏览器窗口或二次验证码，说明服务器要求交互式认证；而没有提示的静默失败，说明客户端根本没走到被询问的那一步。

Material	Typical lifetime	What invalidates it
Cached password	Until changed	Account or password policy change
Session token	Minutes to hours	Expiry, revocation, reauthentication policy
Tunnel SA or TLS ticket	Configured rekey interval	Rekey, network change, peer restart

密钥更新会替换密钥，但保留已认证的身份，所以健康隧道上它会隔一段时间静默发生一次。重新认证则会重做身份核验本身，需要你介入的正是这件事。IKEv2 明确区分两者，对端可以按设定间隔要求完整重新认证，而不管中间发生过多少次密钥更新。从外部看，两件事在读到日志说的是哪一件之前完全一样。

OpenVPN 在自己的术语体系里也是同样处理：重协商间隔刷新数据通道，认证令牌可以交还客户端，以便下次连接时免去完整登录。该令牌有生存期，是否再次接受由服务器决定。

所以同样一次重连，八分钟后能成功，八小时后却可能失败，而两端配置毫无变化。只在午饭后出现的提示，全部解释就在这里。

要求浏览器步骤的策略，会在无法展示该步骤的客户端上失败。无图形界面的服务器、启动脚本，以及只为纯密码认证构建的旧配置，都会撞上这堵墙，而失败常以通用超时而非认证错误的形式出现。

设备与网络的切换也可能落进策略评估窗口，于是从 Wi-Fi 切到热点的漫游，正好与一次本来就会发生的检查重合。这种巧合让网络背了锅，而真正的原因是定时器。

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

第一行显示客户端自身日志里的重协商与认证事件，第二行显示 strongSwan 对端当前持有的安全关联。把时间戳与提示出现的时刻对照；吻合就证明是定时器而不是网络。

如果手动登录能成功、自动复用却持续失败，就把这一点原样告诉运维。它点明了组件：是复用路径，而不是凭据。附上失败时间、所用账户，以及你看到的提示类型。

不要为了把重连变安静而关闭二次验证、跳过证书校验，或把凭据写进脚本。这些做法都会拆掉策略本要强制的检查，也都会把一次登录提示变成一次事故。

应当索要受支持的流程：能完成挑战的客户端、与工作日匹配的令牌生存期，或为无法提示的机器批准的免交互配置。这些都是有人可以批准的配置决定，而绕行不是。