每小时一次的 OpenVPN 掉线：重新协商还是真正的重连？

六十分钟、三十分钟，或者一百二十分钟：落在整数间隔上的掉线，几乎从来不是网络的问题。OpenVPN 按计时器刷新保护数据通道的密钥材料，而比你设想更短的计时器，看起来完全就是一条反复失败的链路。用户报告连接中断，日志却报告密钥交换成功。下面的步骤把这种刷新与真正的重启区分开，读取实际生效的值，并且只有在代价摆上桌面之后才去改动它。

请按顺序执行。第一步决定这一页的其余部分是否与你有关，跳过它，你就会花一晚上去调整一个与故障无关的计时器。

区分软重置与重启

日志行就是全部诊断。重新协商会在同一条隧道里写入一次软重置，随后是一次全新的密钥交换：接口保留地址，路由不会被重新添加，已建立的 TCP 会话通常只是短暂停顿后继续存活。真正的重连会撕掉会话、重建接口、可能分配另一个客户端地址，并杀死所有长连接。两种事件都很普通，只有其中一种能解释一次掉线的通话。

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

版本行之所以重要，是因为日志措辞会随版本变化，你记得的 2.3 的消息在 2.6 里可能写法不同。请读你自己的日志，而不是别人论坛里的摘录。求助时请引用确切的那一行，因为转述会丢掉识别事件的关键细节。如果事件前后接口地址没变、会话列表也还在，你看到的就是一次刷新，后面的章节都适用。

读有效计时器，而不是你的配置文件

reneg-sec 是数据通道两次重新协商之间的秒数，默认值是 3600。每一端各带自己的值，实际触发刷新的是两者中较小的那个。这一条规则解释了大多数报告：客户端配置文件设了很大的数，但服务器保持默认时，它照样每小时被重置。

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

在从客户端文件下结论之前，也要读服务器的有效配置，包括它下发的所有内容。然后把详细程度调高，完整观察一个间隔：级别 3 已经会显示重新协商的行，而时间戳会告诉你这件事是每 3600 秒重复一次，还是跟着活动走。

要在真正被下发的地方修改

流传的偏方是在客户端配置文件里加一行，而大约一半的情况下那是错的地方。因为较低的一端取值获胜，把计时器设为零的客户端，仍然可能被没有改动的服务器重新协商。

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

如果配置文件是集中生成的，请改模板而不是已部署的副本，否则下一次置备运行就会把你刚删掉的值恢复回去。验证要看两个间隔，而不是一个：仅仅安静一小时，与把计时器设成 7200 也完全相容。

还要决定混合部署时会发生什么。如果先把改动推到客户端，就会留下一段窗口，服务器仍在触发刷新；这本身无害，但如果你盯着日志等确认，就会很困惑。先改持有较小值的那一端，症状就会在你预期的位置消失。

关闭重新协商要放弃什么

定期重新协商限制了同一组数据通道密钥能保护流量多久。关掉计时器不会弄坏隧道，在家庭路由器或小型办公网关上，实际暴露也有限。但它仍然是一笔交换，动手之前值得把它说清楚。改变的是同一组密钥保护会话的时长，而不是隧道还能不能工作。

合理的关闭理由是：某种重置会破坏无法恢复的东西，比如掉线的通话、必须重建的远程桌面会话、从头重跑的备份。如果那点停顿用户根本感觉不到，保留默认值不花任何代价，还能留住你已有的密钥轮换。

只要情况允许，优先修根因。第一次握手成功、刷新却在半路失败，指向的是路径而不是计时器：去找更大规模控制通道交换里的包大小问题、丢弃流量的有状态防火墙，或者只在第一次尝试才成功的提案。它们中的每一个都会在你刚读过的同一份日志里留下痕迹。关掉计时器会把证据藏起来。

当间隔指向别处时

配置里的两个邻居会产生相似的症状，却需要不同的修法。ping-restart 在设定的时间内没有数据到达时重启隧道，而 ping-exit 会把客户端彻底断开。日志里任何地方都没有重新协商的空闲掉线，属于这两者，或者属于按自己的日程让 UDP 映射过期的 NAT 设备。

消费级路由器、手机热点和运营商级 NAT，都会在无人告知的情况下让空闲的 UDP 会话过期。这种故障跟随的是空闲而不是时钟，这正是识别标志：一个在安静十分钟后掉线、却能扛住一小时稳定流量的会话，并没有在重新协商。

改动第四项之前，先记下三件事：你测到的间隔、你找到的有效值，以及显示它的命令。如果计时器一动间隔就跟着动，机制就确认了，修法就是对上面那笔交换做出决定。如果它不动，就把设置改回去，继续盯 keepalive、NAT 状态和丢包。