VPN 总在同一间隔断开？对上那个计时器
固定间隔的掉线是指纹。在动手改动之前，先比较隧道密钥重协商、NAT 空闲计时器、DHCP 租约和账户限额。
每十五分钟死一次、或整点同一分钟死一次的隧道，说明某个计时器到期了，而不是网络不稳定。有用的做法是把这个间隔记下来，再与产生这种模式的四个计时器逐一对照。在对照之前就改超时，通常只是把故障挪了个位置而没有解释它，下一次会比第一次更难读。这项测量只要十分钟，却能省掉一周的猜测。
把间隔变成一个数字
收集五六次发生，计算它们之间的间隔，而不是从当天零点算起。09:12、10:12、11:12 掉线是整点边界；09:12、09:27、09:42 掉线是距上次成功连接十五分钟。把结果归到最可能的计时器上，而不是归到最近的分钟。
每次事件记下两个时刻：流量最后一次移动的时间，以及客户端报告断开的时间。隧道静默死亡、客户端到下次发送才发现时，两者并不相同，而这个差别正是区分空闲超时和硬故障的关键。发现得晚的客户端会把测得的空闲窗口撑大。
注意重连是否自动。几秒内自动重连的客户端会让间隔留在日志里、不进入用户报告，所以这类故障常被说成偶发而非周期。它也让使用笔记本的人看不到这次事件。
四个长得很像的计时器
几乎所有反复掉线的隧道都出自其中之一：协议密钥重协商、空闲映射过期、DHCP 或接口事件，或者账户策略。它们的区别在于当时有没有流量，以及边界处日志说了什么。
下面这些特征值得记住，因为它们能让你用一行日志排除三种解释：
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
第一行是正在履行职责的安全机制，第二行是忘记状态的中间设备。把两者搞混，要么会削弱密钥重协商，要么会去追一条从未参与过的防火墙规则。
忙与闲告诉你哪一半
用持续流量做一次受控对比，比如朝隧道内主机跑一条长流，看间隔是否变化。如果在有数据流过时不再掉线，计时器就是基于空闲的。
如果持续流量下仍然掉线，触发点属于密钥重协商、租约或策略。这一次测试大约一小时观察就能排除一半候选，成本只是注意力。
测试期间保持接入网络不变。在对比中途切换 Wi-Fi 与以太网，恰好引入你想与计时器区分开的那类接口事件。
把日志行与边界对上
读记录时刻附近的客户端和服务器日志，而不是整个文件。密钥重协商会显示协商过程；空闲过期直到下一个包才有东西；租约变化会显示地址操作；策略限额通常显示干净的主动断开。
下面这些命令可以从各来源取出相关时间窗：
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show如果三个来源在时间戳上一致，你就找到了计时器的主人。如果只有客户端日志有内容，结束会话的大概不是服务器。
修的是环节，不是图标
每个主人只有一种受支持的修法。密钥重协商失败需要两端提案兼容。空闲过期需要在路径允许的范围内加保活或缩短空闲预期。租约事件需要处理接口或电源设置。账户限额是策略决定，不是缺陷。
为了图标变绿而关掉密钥重协商或身份验证，是用看不见的弱点换看得见的掉线，而且让你说不出隧道上次协商新密钥是什么时候。之后重新测原始时长并保留时间戳，下一次事件就能与这次对比，而不是从头再来。