站点隧道恢复后的备用租约：续租还是等待？

站点链路已恢复，隧道已建立，但分支的电脑仍然无法访问文件服务器。故障期间有两个时钟在走，而只有一个已经走完。加密路径恢复时，隧道随之恢复；每个客户端的地址则要等当前租约到期或被替换后才会恢复。比较这两条时间线，比翻看防火墙日志更快解释清楚落差。

两个时钟，而其中一个并不是隧道

在 VPN 上运行 DHCP 并配有本地备用方案时，只要远程 DHCP 路径不可用，设备就可以下发临时的本地租约。临时时长通常以分钟计，短到足以掩盖问题，又长到能撑过一次短暂中断。隧道恢复后，备用方案停止提供这类租约。它不会进入客户端去取消客户端已经持有的租约。该客户端会保留地址、掩码、网关和解析器，直到续约或到期，因此健康的隧道与坏掉的桌面可以在租约剩余时间内并存。

请把具体实现和软件版本与这一说法绑定。定时器名称和默认值在不同 SonicOS 版本之间并不相同，旧界面并不能证明新界面会做什么。

比较两种恢复动作

动作 A 是等待。它不花成本，不担风险，让每个客户端按自己的时间表续约。动作 B 是在受影响的客户端上强制释放并续约，这样能立刻拿到预期地址，但会打断客户端正在做的一切。在单台桌面上，强制续约通常是更快的路径，也容易说明理由。在实验室里，或在交易进行中的收银终端上，等待是更稳妥的选择，而安排在非工作时间的续约比两者都好。

ipconfig /all
ipconfig /release
ipconfig /renew

在释放任何东西之前，先读输出。如果地址、网关和 DNS 已经与正常作用域一致，说明客户端已自行恢复，剩下的问题在别处。在 Linux 客户端上，等价做法是通过网络管理器释放并续约租约，而不是手工改地址，否则管理器会在下一个事件里把你的改动写回去。

要读提议，而不只是地址

只看地址并不能说明是谁提供的。关键在提议中的服务器标识、租约时长，以及网关和解析器匹配的是备用作用域还是正常作用域。

tcpdump -ni any 'port 67 or port 68'

在续约期间抓包，因为安静的接口说明客户端从未发起请求。如果隧道还在时提议却来自本地备用方案，说明选择逻辑仍把远程路径当作不可用，此时在客户端上强制续约只会重复同样的结果。把抓包结果与同一时钟上的隧道事件对照起来。在客户端请求前几秒结束的密钥更新或短暂中断是可能的原因；隧道干净却收到备用应答，则是选择路径上的配置问题。

比较在何处反转

如果大量客户端同时受影响，逐台续约就会变成一串中断和一次支持电话。这种情况下应查看备用作用域和恢复流程，而不是客户端，因为这一群是一起恢复的，也会再次一起恢复。

如果只有一台客户端受影响而邻居正常，结论正好相反：变量是这台客户端的租约、保留地址或它自己的 DHCP 客户端行为，而全站改动是错误的工具。

静态地址和保留地址需要第三种答案。被钉死在某个地址上的客户端无法靠续约救回，而与备用作用域冲突的保留地址会产生重复，看起来像路由故障，直到你把两套地址规划对照起来。

把退出流程写下来

事先决定备用的用途、客户端可以保留临时地址多久，以及谁有权在工作时间强制续约。把答案写在值班工程师能找到的地方，就放在作用域定义旁边。然后有意测试一次：断开隧道，观察客户端收到什么，恢复隧道，并记录客户端要多久才能拿回正常设置。这一次演练，就能替代下次站点链路抖动时的大部分猜测。

最后要确认的是资源，而不是地址。访问文件服务器、解析它的名字、访问互联网，是三项独立的检查，而只有最后一项从未有过疑问。