为什么 Azure OpenVPN 隧道大约每六十秒就断开

隧道完成了握手，承载约一分钟的流量，然后重新连接。这个顺序排除了常见的嫌疑：若是防火墙封锁端口，握手就会失败，而不是会话。你遇到的是活性判断的分歧：一侧认定另一侧已经静默，于是拆掉了一条正常工作的隧道。日志行会说明是哪一侧，而它决定了修复方式。

在调整任何计时器之前，先读那一行。

迷思：路径中有东西在阻挡隧道

如果端口被封，连接会一开始就失败并一直失败。反复出现的循环说明控制报文在流动、会话在建立，而对话后段的某个东西在不断过期。封锁产生的是沉默，而这里产生的是节奏。

节奏才是有用的线索。计时器会产生节奏；丢包很少会。

先读断开原因，再谈计时器

OpenVPN 会为原因命名，每个名字指向不同的子系统。Session invalidated: KEEPALIVE_TIMEOUT 是计时器到期，所以要比较两端的 ping 和 ping-restart 取值。AUTH_FAILED 是凭据或证书状态，改计时器没有用。TLS 错误意味着双方根本没走到 keepalive 阶段。

记录连接时间、断开时间，以及间隔是否精确到秒。仅凭这一项测量，就能把配置好的计划与巧合区分开。

间隔稳定就是计时器。间隔漂移更可能是路径问题或会话被顶替。

两个从未对齐的 keepalive 计时器

从门户导出的配置文件有时仍带着从社区服务器模板复制来的 keepalive 或 ping-restart 行。网关运行自己的死对端检测并施加自己的预期，两套时间表不必一致。两者不一致时，客户端就会按照网关从未同意过的时间表重启。

这两个值不是同一种控制。ping 是客户端发送回声的频率，ping-restart 是在拆掉隧道之前等待多久而听不到任何回应。把 ping-restart 设得很短、而网关应答很慢的配置，会在每个安静时段重启，这正是六十秒循环的形状。

客户端侧最小的改动，是在配置文件顶层、每个内联块之外，把计时器置为无效：

keepalive 0 0

保存，重新加载配置文件，重新连接。已经进入内存的会话会保留旧值，所以有时这次修改看起来毫无作用。

证书名称可能在你脚下变化

Azure 证书认证依赖于客户端信任网关今天出示的名称。旧下载里的 verify-x509-name 行会固定一个名称，而网关重建或证书续期后该名称已经变了；这种不匹配表现为重连循环，而不是明确的错误。删掉这一行能恢复连接，因此它是不错的诊断手段，却是糟糕的长期修复，因为同时也去掉了校验。隧道稳定之后，用网关实际出示的名称恢复这一行。

在修改网关之前，先在同一台机器上测试第二代客户端。如果一个客户端反复循环、另一个保持稳定，问题就不在配置文件。

该改什么，按什么顺序改

接下来检查会话是否被顶替。两台设备共用一张证书会互相把对方挤下线，结果看起来是周期性的，因为两边都在不断重连。比较同一身份反复出现的点到站点会话记录。

然后运行几分钟持续流量来测试空闲路径。如果流量持续时断开停止，那么关键计时器属于路径上的 NAT 设备或负载均衡器，而不是 OpenVPN。

只有在完成这四项测试之后，才应该改动网关设置。