设备时钟错误会让 VPN 连不上：先看时间，再换证书

VPN 突然连不上，日志里提到证书，第一反应就是换配置文件。设备时钟差上几分钟甚至几小时，产生的正是这个错误，因为证书有效性是相对本地时刻判定的。屏幕上的时区标签不是问题，底层的时间才是问题。在碰任何证书材料之前，先检查时钟。

报错看起来像证书问题，其实是时钟问题

当对端证书相对于校验方时钟落在有效期之外时，TLS 握手就会失败。这项检查在客户端执行，所以客户端时钟错了就会拒绝一张完全正常的证书。报错文本点名证书，于是人们换掉证书，然后又看到同样的失败。时钟是成本更低的假设，应该先验证。

快于真实时间的时钟会把当前证书判为已过期；慢于真实时间的时钟会把更新的证书判为尚未生效。两种提示都指向日期，而且都不用联系证书颁发机构就能产生。这正是线索：真正过期会影响所有客户端，时钟问题只影响那一台时间不对的机器。

在做任何改动之前，先打印 UTC 时钟和证书自身的日期。比较两个绝对时刻，就能把时区问题彻底移出排查范围。如果证书有效期包含当前时刻，证书就不是失败原因。

date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

如果本地时钟不对，检查它是否在同步、同步到哪个源。关闭同步、或时间源不可达的机器会一直漂移，直到某个环节坏掉。状态输出会给出源和最近一次成功调整，这比只看当前偏差更有用。没有配置源的大偏差，与相对正常源的小偏差是不同的问题。

timedatectl timesync-status
chronyc tracking

如果证书对所有客户端确实都已过期，就停下来。此时时钟没问题，证书需要续期而不是调整。

基于时间的一次性密码从当前时间步取值，通常是三十秒。时钟偏移超过一两步的设备会生成服务器不接受的验证码，即使使用者输入的数字是对的。报错看起来像密码错误，于是人被带进重置循环，而重置修不好时钟。

先弄清是哪一环拒绝了尝试，因为 VPN 客户端、网关和身份提供方报告的是不同阶段。如果验证码被拒而密码被接受，账户多半没问题，时钟才是嫌疑点。如果两者都被拒，账户可能被锁定，时钟就是干扰项。按提供方的恢复指引处理，不要批准不是你自己发起的验证请求。

不要为了验证码能用而把时钟往回拨。这会掩盖原因，并破坏下一次基于时间的检查。

时间同步是网络服务，隧道会改变时间源是否可达。企业内网源可能需要隧道，公共源可能被策略阻断。浏览能用而时间服务自己的路径失败，这种情况很容易被忽略。NTP 是调整背后的协议，它需要和其他服务一样的独立路径。

sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20

还有启动顺序的问题：严重错误的时钟可能让带认证的隧道建立不起来，而唯一可用的时间源可能就在那条隧道后面。受管机群需要针对这种状态的成文流程，绕过证书校验并不是流程。个人设备上，使用操作系统自带的校时功能，并查明关机或恢复后时钟为什么会丢。每次开机都漂移的机器是硬件或配置问题，不是 VPN 问题。

修好之后，重新尝试原来的连接，并单独读新的报错。服务器身份不匹配、证书确实过期、账户被拒是三种不同的失败，把它们混在一起，才会让一次简单的校时变成一周的换配置。