IKEv2 的死亡对端检测不会测试你的应用

IKEv2 存活检查只问一个问题：对方对端是否仍在受保护的控制关系上应答。它不衡量内部应用是否健康、网关之后是否存在路由，也不衡量浏览是否感觉快。即使隧道后面所有有用的东西都失灵，这项检查仍可能通过。

在改动计时器之前，把两类证据分开来读。

存活检查实际在问什么

一次存活交换在已建立的 IKE 安全关联内部发送，并期望在配置好的时间窗内得到应答。成功意味着对端的 IKE 实现仍然在，并且仍然愿意对话。它对承载流量的子安全关联只字未提，对网关之外的路由也只字未提，对你为哪项服务打开隧道同样只字未提。这是三个彼此独立的问题，对应三种彼此独立的失败方式。

这个区别决定了会话安静下来时该往哪里看。数据路径已断而对端仍在应答，指向的是策略、路由或下游服务。对端停止应答，指向的是可达性或远端自身的状态。

向守护进程询问时，控制状态与数据状态是分开列出的，而计数器会告诉你到底有没有尝试过。从未安装的子关联，与安装后又停止转发报文的子关联看起来完全不同，尽管两者带来的是同一句用户抱怨。

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

把状态名原样记入工单，并附上抱怨那一刻的计数器。像隧道已断这样的描述会掩盖两条关联中究竟哪一条结束了，而这通常才是唯一值得留下的事实。

网关可以应答控制交换，同时内网服务器离线、转发路由缺失，或者内部域名解析彻底失败。从客户端看，这些情况全都表现为会话是通的、目标却不通。返回路径要像去程一样仔细检查，因为远端的非对称路由只会在一个方向上造成沉默。

直接测试目标应用，并说出它尝试的地址，而不是测试隧道是否通。对网关做 ping 只能证明网关会应答，从来没有证明应用会应答。记录应用尝试过的确切地址。这个字符串日后能缩小排查范围，而它往往是工单唯一漏掉的事实。

缩短检测间隔既不是性能改动，也不增加容量。在丢包条件下，它改变的只是故障被多快识别出来，可能让症状看起来不同，却什么都没改善。先记录故障的真实时间，再判断这个容差对实际链路是否不合适。

NAT 映射刷新属于同一类。它们让转换后的路径保持可用，并不能证明远端应用工作正常。

一份完整的恢复策略要说明：当某个对端被判定为死亡时，客户端应当做什么，是重启、关闭还是保持；以及在此期间其他流量可以做什么。没有它，同一个事故每季度都要从零重新诊断一遍。