H3C MER5200 对接奇安信 IPSec 不定时假死断开

现象：MER5200 两条 IPSec 隧道，对接 H3C 防火墙隧道稳定；对接奇安信隧道，60‑70 台设备大流量实时业务，不定时假死 / 断开；另一条 H3C 隧道一直正常。

是否设备性能跟不上？

MER5200 的 IPSec 加密吞吐有限，60‑70 台终端同时跑实时业务有性能压力，但不一定就是硬件瓶颈。优先排查厂商兼容、IKE 重协商、保活、老化时间，最后看 CPU 占用。

假死典型表现：Web 显示隧道还在线，但业务不通；或者直接隧道断开重连。

排查步骤（按优先级）

1、查看故障时刻设备 CPU、内存（最优先）

故障发生时登录 Web / 命令行，看 CPU 利用率。

• 如果 CPU 长期持续＞80‑90%：就是加密性能瓶颈，大流量加密把 CPU 打满，IKE 保活报文处理不过来，隧道假死断开。
• 如果 CPU 正常（＜60%）：属于不同厂商 IPSec 兼容问题（MER ↔奇安信）。

2、IKE/IPSec 生命周期、保活参数（第三方对接最高发）

不同厂商默认老化时间不一致，大流量下 IKE 重协商失败，隧道僵死。

1. IKE SA 生存时间、IPSec SA 生存时间，两端必须尽量接近
   • MER5200 默认 IKE：86400s；IPSec SA：3600s
   • 奇安信修改为和 MER 保持一致，不要设置过小。
2. 开启 DPD 死亡对端检测（两端都开） DPD 探测间隔建议 30‑60 秒，超时 3 次拆除旧隧道，触发重新协商；不要关闭 DPD，关闭极易出现假死（隧道显示 up 实际不通）。

现象：大业务流量把 IKE 协商报文淹没，DPD 关闭时设备不知道对端已经异常，隧道状态卡死。

3. 确认 NAT‑T：两端开启 NAT 穿越 UDP4500，公网有 NAT 环境必须开启。

3、感兴趣流（加密 ACL）检查

1. MER5200 和奇安信两端加密流量 ACL 必须镜像完全对称；
2. 60‑70 台终端产生大量源端口随机的会话，不要写细粒度的多条小网段，尽量聚合大网段作为感兴趣流；

细分大量子网段，高并发下容易出现 SA 匹配异常。

4、MER5200 设备版本

老固件版本存在第三方 IPSec 对接 bug，升级 MER5200 到官网最新稳定版本，很多跨厂商隧道不稳定通过升级固件解决。

5、NAT 策略确认

确认 MER 的NO‑NAT（不做 NAT）策略完整覆盖走 VPN 的内网网段，大流量下避免部分流量被 NAT 错误转换，导致隧道异常。

区分两种故障现象

1. Web 页面隧道状态显示【已连接】，但是业务完全不通（假死）

根因：DPD 未生效，SA 老化没有正常重协商。解决：两端开启 DPD，调生存时间，升级固件。

2. 隧道直接断开，重新自动建立

根因：公网链路抖动；或者 CPU 打满；或者 SA 重协商参数不匹配。

性能瓶颈判断

故障时 CPU 持续高，加密性能不足：

• 短期方案：对该隧道业务做 QoS 限流，降低 VPN 隧道的流量压力；
• 长期方案：更换更高 VPN 加密性能网关。