停电后路由器 VPN 看起来正常？请检查这四个层面

停电后亮起的路由器只是恢复了配置，并没有恢复连接。停电后，路由器可能在配置所需的依赖项就绪之前就恢复了已保存的 VPN 配置文件：上游调制解调器可能仍在训练，时钟可能不正确，身份验证可能尚未完成。面板指示灯和已保存的配置描述的是意图，而不是可用的隧道。请按顺序检查下面四个层面，而不是更换配置文件——人们往往第二件事才做这个，却第一件事就后悔。

这里的一切都假定你在现场，或者 有一条不依赖你正在测试的隧道的进入通道。如果没有，请在下一次停电前安排好。

第一层：WAN 真的恢复了吗

从调制解调器开始，而不是路由器的面板。如果路由器在其调制解调器完成训练之前就完成启动，它会显示一个背后空无一物的健康接口，而隧道也没有可到达的对端。确认调制解调器确实在转发，然后确认路由器已取得你预期的 WAN 设置。还要检查 WAN 地址是否发生变化：动态地址如果返回时不同，可能使基于地址的规则或远程允许列表失效，而从网络内部看，这就像 VPN 故障。

有些接入网络在停电后还需要新的准入步骤。与其猜测，不如读取客户端日志中的第一个失败阶段：第一个错误会指出层面，之后的一切都是结果。请把地址和准入结果记入工单，因为这两者决定了同一配置文件明天是否可用。地址变化是五分钟的修复，也是两小时的谜团。

第二层：先检查时钟，再检查证书

时钟错误会干扰证书有效期以及一切基于时间的东西，而没有可用时间源就启动的嵌入式设备可能在一段时间内停留在旧日期上。此时证书校验会因与凭据毫无关系的原因失败。日期偏差数年的有效期错误指向时钟；同样错误但日期是当前日期，则指向证书。

date -u
chronyc tracking

使用受支持的时间恢复流程，并在改动配置文件之前确认路由器时钟。为了绕过错误而关闭校验，会把临时的顺序问题变成永久的削弱，而这是此场景中最常见的错误修复。如果设备没有电池供电的时钟，启动顺序就很重要：它需要先有网络访问才能同步时间，也需要先有时间才能验证隧道。如果每次停电后都重复同样的失败，需要修复的正是这个顺序。

第三层：读懂隧道在说什么

检查隧道自身的状态以及握手或认证的结果，而不是接口是否已启用。接口可以在没有建立对端的情况下存在，客户端也可能在密钥更新失败时显示为已连接。要把传输超时与明确拒绝区分开：超时说明路径或对端尚不可达，而拒绝意味着远端已回应并拒绝，通常是因为凭据、证书或不再匹配的对端身份。因为超时就让用户去重置密码，会浪费所有人的下午。

把最后已知的良好配置放在手边，以便比较字段而不是重建它们。如果某个字段变了，那个变化就是发现。要把它与恢复后的配置逐字段比较，而不是只读恢复后的那份。停电后的多数意外，都是一个悄悄退回模板默认值的字段。

第四层：从下游设备测试

从路由器后面的客户端打开一个无害且被允许的资源，然后确认流量实际走了哪个出口或私有路由。检查 DNS 以及你声称覆盖的每个地址族，因为路由器自身的探测可能成功，而客户端策略仍然是错的——探测常常使用不同的源、不同的表或不同的解析器路径。

curl -s https://ifconfig.me
nslookup example.com

如果隧道已中断且不只是配置错误，就要决定受影响的客户端必须被阻断，还是可以使用已批准的备用方案。这个选择属于停电前的故障转移计划，而不是停电期间的聊天线程。把观察到的出口和解析器写进停电工单。现在写两行，就能为下一个人省下一小时猜测窗口期内哪条路径是通的。

怎样修，才能让下一次停电更短

如果失败重复出现，那么要修的是顺序，而不是配置：先让 WAN 起来，再让时间，再让隧道，再让客户端策略。多数路由器把这表达为依赖关系或延迟，而一个短暂的刻意延迟胜过重写配置文件。

然后在修改后重复常规重启测试，包括客户端侧的检查。只看路由器面板的重启测试，测的是四个层面中信息量最少的那个。