自动化 ASA 隧道重置：放行前的三道闸门

把自动隧道重置看作一次带有影响半径的恢复操作，而不是按计划发作的情绪波动。你面前的判断比工具所暗示的更窄：哪种故障值得触发它、它可能触及哪个对端、什么条件下它会停下。这三件事错一件，你就造出了一台删除证据的机器。我曾见过某套这样的逻辑整整一周里每十五分钟就对一条健康的隧道开火，却没人察觉，因为隧道每次都会自己恢复。

第一道闸门：证明故障在隧道内部

在授权任何动作之前，先关联最新状态。show crypto ikev2 sa detailed 告诉你 IKEv2 关联是否存在、协商走到了哪一步，show vpn-sessiondb detail l2l 给出与同一对端对应的会话视图。接着 show crypto ipsec sa peer 203.0.113.10 显示子 SA、encaps 与 decaps 计数器以及正在使用的选择器。encaps 计数器持续上升而 decaps 计数器不动，与完全没有关联是完全不同的问题。

其次，检查重建无法修复的东西：缺失的返回路由、吞掉大包的 MTU、解密后拒绝端口的策略，或把应答绕过设备发送的非对称路由。对着其中任何一种清 SA，只会换来短暂的绿色闪一下，以及明天同样一张工单。这些问题在应用侧都像隧道已死，所以计数器比告警更值得相信。

动手之前先留快照。记录对端、关联标识、触发时刻的计数器，以及触发它的证据。抢在快照之前执行的重置，会摧毁这起事件中最有价值的数据。

第二道闸门：范围只限对端，绝不放眼全局

在 ASA CLI 上，clear crypto ikev2 sa peer 203.0.113.10 与 clear crypto ipsec sa peer 203.0.113.10 是定向操作。同样两条命令若不带对端参数，就会清掉该上下文中的全部关联，于是一字之差变成了效果上的全面中断。Cisco 的 clear 命令参考 把这些形式与仅重置统计的变体区分开来，后者只清计数器，什么也修不好。在多上下文模式下，命令只作用于当前上下文，所以自动化还必须确认自己处在哪个上下文。

在拼出命令之前先校验对端。空值或未解析的变量必须让任务响亮地失败，而不是坍缩成一次清空全部；这项检查应当放在评审者读得懂的代码里。

如实画出影响半径。一个对端可能承载多个受保护网段、数千条会话，以及一条用于管理的第二隧道，因此在集线器上，限定对端的清除仍然是一次多客户事件。请从一条不依赖被测隧道的管理路径执行操作。否则自动化无法验证自己的结果，下一步就是有人开车去现场。

第三道闸门：重试、冷却、定义成功

给任务加上按对端的锁、冷却期，以及依据最新观测计数的硬性尝试上限。没有锁，两个同时触发的监控会在重新协商进行中清除同一个对端，而且各自都认定是对方失败了。

成功意味着关联已经回来、被许可的业务能够通过，而不是命令返回时没有报错。用当初发现故障的同一项检查去探测，再确认子 SA 计数器双向都在动。隧道仍然不通而命令以零退出，这是披着恢复外衣的监控失败。

把未知与失败分开记录。如果遥测已经过期，或管理路径不可达，诚实的状态就是未知；重试预算不该把这种未知读成再次开火的许可。

当第一次获批的恢复没能恢复服务时，带着快照升级处理，而不是反复循环。定时重置是这类模式里最糟的一种，因为它在按计时器切断健康会话的同时，把密钥重协商、路由或策略上的缺陷藏了起来。

归属、一个关闭开关与一次演练

指定负责人，写清如何一步停用该小程序或计划任务，并设定复核日期。没有停用路径的自动化，会在作者换团队的那天变成永久基础设施。

在实验室或维护窗口里，故意打坏对端选择来演练，弄清任务是否会安全失败。然后再演练成功路径，因为只在出问题时才运行的任务，不会告诉你它正常时是什么样子。