监控 IPsec 隧道接口：该读什么

基于路由的 IPsec 设计会安装一个虚拟接口，而这个接口给监控提供了一个具体的对象：一个有名称、有计数器、并绑定了一条路由的东西。它本身并不是健康信号。接口可以存在，而没有任何可用的关联被安装；关联也可以健康，而没有路由把关注的流量送往它。把四种状态放在一起读，才能把数据包计数变成诊断。

按顺序逐一检查，并在第一个失败处停下。

接口给整体图景增添了什么

在基于策略的设计中，选择逻辑存在于 IPsec 策略表中，内核根据流量选择器决定保护哪些流量。基于路由的设计增加了接口和路由，因此 tcpdump 和接口计数器看到的是一个边界，而不是一组选择器。这对诊断，以及对需要接口来建立 peering 的路由协议来说，都是实实在在的收益。

收益是管理层面的，而不是密码层面的。接口报告它所承载的流量，却完全不说对端的保护当前是否可用。

在责怪隧道之前先读四种状态

先从接口和路由开始，然后是关联，最后是应用。每一层都有自己的命令和自己的失败特征。一层干净并不等于下一层也干净。得出任何结论之前，四者都要运行。单凭一条绿色的输出，很少能说明问题。

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

计数器在增长却没有对应状态条目的接口，说明流量进入了一条没有任何保护的路径，这比隧道单纯中断更糟。状态条目存在，却没有选择该接口的路由，意味着加密已经就绪但未被使用。

应用测试放在最后是刻意的：能 ping 通隧道对端，并不能证明其后的服务接受连接。

比较内层计数器与外层计数器

隧道接口上的计数器衡量内层流量；物理接口上的计数器和抓包显示封装后的交换。两者不会一一对应，因为封装会增加首部，重传会复制部分数据包，而实现的统计有自己的规则。应期待一个比例，而不是相等。

抓包位置也决定了你收集哪些私有数据，因此应使用狭窄的过滤器和一个无害的测试地址，而不是完整抓取生产流量。

如果内层计数上升而外层没有，缺失的一步通常是把数据包送进隧道的那条路由或策略，而不是隧道本身。

在密钥更新和故障切换中观察它

在观察同样四种状态的同时，观察一次密钥更新、一次死对端检测事件和一次链路故障切换。接口可能在一次永不完结的密钥更新中依然存在，而故障切换可能留下一个指向已无法到达的对端地址的状态条目。

针对你真正依赖的服务路径告警，把关联状态作为上下文，而不是依赖单一的上/下标志。把接口名、对端地址和路由保留在告警负载中，让响应者不必重新拼凑它们。

strongSwan 记录了自己的 XFRM 接口模型，其他平台对等对象的命名和实现方式并不相同。在把另一套实现中的假设搬过来之前，先读一读针对你面前设备的基于路由的对比。适合某一厂商计数器的监控模板，在另一家身上会悄悄误导你。