日志要按时间线读
IPsec 故障在日志里表现为一串事件：协商请求、SA 建立、重协商、SA 删除与伴随的业务告警。单独看某一条告警往往得不出结论，把它放回时间线上，观察「建立是否晚于业务恢复请求」「删除原因是什么」「与链路抖动或路由切换是否同一时刻」，才能定位到真正环节。两端日志都必须收集：一端只有请求没有响应，说明响应侧丢包或被策略拦截；两端都有请求却都失败，多半是参数无交集或认证失败。
基本信息
| 建立事件 | SA established，通常记录对端地址与协商出的算法 |
|---|---|
| 删除事件 | SA deleted，注意删除原因字段，常见为超时、管理员清除或对端请求 |
| 异常告警 | 如收到未加密报文被丢、DPD 超时、认证失败 |
| 采集方式 | 设备本地日志、syslog 服务器、journalctl 系统日志 |
| 分析要点 | 统一时间基准后与业务告警、链路事件对齐 |
典型使用场景
- 隧道反复重建：观察删除原因与重协商周期是否规律
- 业务中断定位：确认是否伴随 SA 删除，或 SA 一直在而转发有问题
- 认证失败排查：日志会指出是预共享密钥不匹配还是身份校验不过
- 升级或改配置后回归：用日志比对改动前后的协商结果
- 向对端或运营商报障：用带时间戳的日志说明问题发生在哪一端
常见线索
常见线索
# Cisco：按关键字过滤关键类别日志
show logging | include CRYPTO|ISAKMP|IPSEC
# 典型告警：收到未加密报文而被丢弃
# %CRYPTO-4-RECVD_PKT_NOT_IPSEC
# Linux 侧 strongSwan
journalctl -u strongswan | grep -E 'established|deleted|timeout'
# 记录当前时间与设备时区，便于与对端日志对齐
show clock日志线索与判断
| 线索 | 可能原因 | 下一步 |
|---|---|---|
| 周期规整的 SA deleted | 生存期或 rekey 参数到期 | 核对两端 rekey 与生存期设置 |
| 收到未加密报文被丢 | 对端未把该流量纳入加密范围或隧道未建 | 比对两端选择符与 ACL 范围 |
| DPD 超时后删除 | 中间路径不通或对端无响应 | 查底层连通与 UDP 500/4500 是否被过滤 |
| 双方都无任何协商日志 | 流量未命中策略或被路由绕过 | 确认加密 ACL 与实际转发路径 |
日志里的时间戳与业务告警时间常存在几秒偏差，跨设备判断因果时把时间基准对齐，不要用秒级差异下结论。
长时间开启加密相关调试会显著占用设备 CPU，排障结束后及时关闭，避免影响正常转发。