六十秒的 TLS 超时：究竟是哪一端停了？

客户端在六十秒后带着一条关于密钥协商的消息放弃，而笔记本这边说不清原因。那句话描述的是客户端的耐心，而不是服务器的行为。三种截然不同的情况都会产生它：数据包从未到达正确的服务、服务在记录任何信息之前就把它丢弃、或者服务拒绝了它并在客户端看不到的地方说了出来。只有把同一次尝试在两端对齐，才能把这三者分开。

给一次尝试一个可以检索的身份

记下带时区的开始时间、配置文件名、客户端实际解析到的目的地、端口，以及连接用的是 UDP 还是 TCP。如果配置文件里有多个远程条目，要记下这次尝试选了哪一个，因为重试可能已经切到下一个条目，而你正在读的文件并没有变化。

要从活动日志里取端点，而不是从你记忆中的下载文件里取。指向私有地址的配置文件完全有效，但从无法路由到那里的网络里完全用不了，而这种情况看起来和服务器宕机一模一样。

然后请运维在目标实例上给出同一个时间窗口。时钟偏差很常见，几分钟的偏移就可能让本应匹配的事件看起来不存在，所以记录偏移量，而不是直接断定没有事件。

四种观察，四种不同的下一步

服务器记录了什么，就决定了走哪条分支。完全没有尝试，指向寻址、传输或通往服务的路径。正常交换之前就消失的入站数据包，指向实际服务的控制通道要求。具名拒绝，指向它所点名的对象。离开服务器却从未到达客户端的回复，指向回程路径。

空的应用日志比看上去更弱。日志记录从交换的某个点才开始，在此之前被丢弃的数据包不会在你读的文件里留下痕迹。在获准的地方，运维可以用服务侧和网络侧的观察来判断到底有没有东西到达。

把四个结果分别记在笔记里。诱惑是把它们合并成“服务器没响应”，而当真正的问题是防火墙规则时，正是这句话把人送去改加密方式。只记下“超时”一词的笔记，已经把你刚付了代价才得到的区别丢掉了。

修好证据所指的那一阶段

TCP 连接完成只能证明有东西接受了套接字。它不能证明监听者是您配置的 OpenVPN 服务；同一主机名上的 Web 服务器能完美回答浏览器，却与隧道无关。

如果服务器报告吊销列表已过期，那比客户端最终的超时具体得多，而修复属于证书颁发机构，不属于网络。如果两端在控制通道保护或共享材料上不一致，重设密码不会有任何改变，因为丢弃发生在检查任何凭据之前。

只改一件证据真正支持的事，然后用同一配置文件对同一端点重试。如果连接有进展，保留第一条新事件，因为那条事件是调查的下一阶段，而不是新问题。

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

延长窗口究竟改变了什么

六十秒是客户端的握手窗口，社区客户端参考记录了调整它的选项。调高它只会让客户端在放弃前多等一会儿。它不会让不存在的服务出现，也不会让被拒绝的数据包变得可以接受。

在慢速链路或高负载服务器上，更长的窗口有正当用途，当你有证据表明交换在缓慢推进、而非根本没有发生时，值得一试。先试它只会把同样的诊断再推迟一分钟，并让时间线更难读。如果时间线显示交换在推进之后卡住，那么窗口是负载的症状，而不是可达性的症状。