MER5200 vpn分支节点连中心节点不上，两边参数一致

您好，检查路由是否配置

官网手册还没有这种案例，如果参数一致的话，

考虑是否nat流量拒绝了 ipsec的流量，导致ipsec一直没办法匹配上。

另外ipsec可以选择  自协商模式和流量触发两种方式。

这种情况，虽然两边参数看起来一致，但 VPN 协商或数据传输的某个环节还是出了问题。你可以按照下面的步骤，系统性地排查一下。

📝 第一步：检查基础网络连通性

这是最基础也是最重要的一步。VPN 隧道能否建立，依赖于两端的公网 IP 是否能正常通信。

• 互 ping 公网 IP：在分支节点的 MER5200 上，用 ping 命令测试中心节点的公网 IP 地址，反之亦然。如果不通，说明基础网络就有问题，需要先解决。

• 检查 NAT 影响：如果分支节点的公网 IP 是经过 NAT 转换的（比如通过运营商的大内网上网），需要确认中心节点是否能通过这个公网 IP 访问到分支节点。这种情况通常需要两端都启用 NAT 穿越（NAT-T） 功能。

• 检查 ISP 干扰：某些运营商可能会限制或干扰 IPSec 流量。可以尝试将两端 IPSec 的端口从默认的 UDP 500 改为非标准端口（如 4500）进行测试，但需要确保两端配置一致。

🔑 第二步：深入核对关键配置

即使你“感觉”参数一致，也建议逐项仔细核对，细微的差异都可能导致协商失败。

• IPsec 策略（保护流）：这是最容易被忽略的地方。在 MER 系列路由器的 Web 界面中，检查“IPsec 策略”下的“保护流配置”。

  • 本端受保护网段/掩码：分支侧应填写自己需要保护的网段；中心侧应填写中心需要保护的网段。

  • 对端受保护网段/掩码：分支侧应填写中心需要保护的网段；中心侧应填写分支需要保护的网段。

  • 核心规则：两端的保护流配置必须是互为镜像的。

• IKE 协商参数：在“高级配置”的“IKE 配置”中检查。

  • 协商模式：两端必须一致。如果有一端是动态 IP，通常要选“野蛮模式”。

  • 认证算法、加密算法、DH 组：这些参数也必须完全一致。

• 预共享密钥：检查两端的密钥是否完全一致，注意大小写和特殊字符。有用户遇到过密钥“神秘消失”的问题，需要重新输入。

• 接口选择：在“IPsec 策略”中，确认“接口”一项是否正确地选择为连接公网的 WAN 口。如果接口是空白的，说明配置可能没有生效。

🗺️ 第三步：检查路由与出口策略

当隧道看似建立但数据不通时，问题常常出在这里。

• 检查路由表：确保分支路由器上有一条去往中心节点内网的路由，下一跳指向 VPN 隧道或对端公网 IP。

• 多 WAN 口场景：如果你的 MER5200 使用了多个 WAN 口（例如专线+ADSL），需要为 IPSec 流量指定明确的出口。配置一条明细路由，将去往对端公网 IP 的流量强制指向专线的下一跳网关。否则数据包可能从错误的接口发出导致协商失败。

🛠️ 第四步：使用命令行深入排查

Web 界面信息有限，命令行能提供更详细的诊断信息。

1. 查看 IKE 和 IPsec SA 状态：

   • display ike sa：查看 IKE 第一阶段（IKE SA）协商状态。正常应显示 RD (READY) 状态。

   • display ipsec sa：查看 IPsec 第二阶段（IPsec SA）协商状态。正常应显示隧道建立成功的相关信息。

2. 查看系统日志：

   • display logbuffer | include IPSEC：过滤查看系统日志中关于 IPSec 的记录，寻找具体的错误信息。

3. 尝试重置连接：

   • 如果怀疑是协商卡住了，可以尝试重置 SA，强制重新协商。

   • reset ipsec sa：重置所有 IPsec SA。

   • reset ike sa：重置所有 IKE SA。

💡 第五步：检查其他常见问题

• 设备性能与规格：确认设备支持的并发隧道数是否足够。

• 软件版本：检查路由器的软件版本，看是否为最新。有时升级版本能解决一些已知的兼容性问题。

• DPD 和生存周期：尝试调整 Dead Peer Detection (DPD) 和 SA 生存周期（Lifecycle）的参数，看是否能改善连接的稳定性。

• 尝试触发流量：有时隧道需要被流量“唤醒”。可以在分支侧尝试 ping 中心侧的内网 IP，看是否能触发隧道建立。

你当前现象：Web / 命令行能查到 VPN 隧道配置、存在协商日志，但IPSec SA 状态为空，代表IKE 一阶段协商成功（有隧道记录），二阶段 IPSec SA 建立失败 / 协商完成后流量无法加密转发，哪怕两端算法参数肉眼一致，依然存在隐性配置不匹配、路由 / NAT / 感兴趣流拦截问题。
一、第一步：基础校验（肉眼看参数一致，实际隐性不匹配，MER5200 高发）
1. IKEv1 协商模式必须完全统一
MER5200 仅支持 IKEv1，两端必须同为主模式或同为野蛮模式，不能一端主、一端野蛮。
Web 路径：高级设置→IPSec→IKE 对等体→协商模式
2. IKE 提议四要素两端一字不差（最容易忽略）
加密算法、验证算法、DH 密钥组、SA 生存时间，任意一项不一致都会出现 “隧道有记录、IPSec SA 为空”
IKE 生存时间建议统一 28800 秒；IPSec 二阶段统一 3600 秒
禁止一端开启 PFS、一端关闭 PFS；两端必须同时开启 / 同时关闭
3. IPSec 安全提议强制统一
安全协议只能选 ESP，AH 协议在有 NAT 场景直接失效；
加密、验证算法、封装模式统一隧道模式；
4. 预共享密钥无空格、大小写完全匹配
复制粘贴容易带入不可见空格，建议两端手动重新输入密钥。
二、第二步：感兴趣流 ACL 配置错误（90% 同类故障根因）
MER5200 是策略型 IPSec，ACL 规则是加密流量筛选器，规则不对称、方向写反直接导致二阶段 SA 无法生成。
标准正确 ACL 写法（两端镜像反向）
中心 MER：源 = 中心内网，目的 = 分支内网
plaintext
acl number 3000
rule permit source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255

分支 MER：源 = 分支内网，目的 = 中心内网
plaintext
acl number 3000
rule permit source 192.168.2.0 0.0.0.255 destination 192.168.1.0 0.0.0.255

高频错误点
ACL 规则写反源目网段；
ACL 包含公网 IP、网关 IP；
多条 ACL 规则重叠、包含关系冲突；
IPSec 策略绑定错 ACL 编号；
只写单向规则，缺少回程匹配规则。
验证方式
内网 PC 互 ping 对端网段，执行命令查看流量是否匹配 ACL：
plaintext
display acl 3000

命中计数无增长 = 流量没匹配加密规则，IPSec SA 无法生成。
三、第三步：NAT 策略冲突（MER5200 必做 IPSec 免 NAT，否则隧道通业务断）
内网访问对端 VPN 网段时，如果匹配上网源 NAT，源地址被转换，流量不再匹配感兴趣流 ACL，二阶段 SA 直接失效。
配置 IPSec 免 NAT（Web + 命令双方式）
Web 操作：上网配置→NAT 策略→新增 No-NAT 规则，优先级放最顶部
源地址：本端内网网段，目的地址：对端内网网段，动作：不做 NAT
命令行完整配置
plaintext
acl number 3000
rule permit source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255
# 免NAT策略
nat policy no-nat
rule 1 permit acl 3000

四、第四步：路由缺失 / 回程路由不对称
IPSec 建立后，内网设备必须有静态路由指向对端内网，下一跳为本端 IPSec 隧道接口。
MER5200 Web 配置路由
网络配置→静态路由
中心路由：目的 = 分支内网，掩码 255.255.255.0，出接口 = IPSec 虚接口 ipsec0
分支路由：目的 = 中心内网，掩码 255.255.255.0，出接口 = IPSec 虚接口 ipsec0
故障现象
只有单向能 ping 通 / 完全不通：回程路由走公网，没有进隧道加密，IPSec SA 状态空。
路由校验命令
plaintext
display ip routing-table 192.168.2.0

输出下一跳必须是 ipsec0 隧道接口，不能是 WAN 公网网关。
五、第五步：NAT-T NAT 穿越开关（两端同时开启）
如果任意一端设备上层有光猫、防火墙做了 NAT（家用宽带 / 多出口场景），必须两端同时开启 NAT-T，否则 ESP 报文无法封装，二阶段协商失败。
Web 路径：IKE 对等体→高级选项→开启 NAT 穿越、开启 DPD 保活检测（DPD 间隔 30 秒）
六、第六步：接口绑定与安全域放行
IPSec 策略必须绑定在公网 WAN 接口，不能绑 LAN 口；
防火墙安全策略放行 IKE 协商报文（UDP500/4500、ESP 协议）：
安全策略：Untrust→Local 放行 UDP500、UDP4500、ESP；
Trust→Untrust 全通，保证内网流量正常发起加密协商。
七、现场快速定位排查操作步骤（按顺序执行）
操作 1：清空旧 SA，重新协商
命令行登录设备，重置两端 IKE/IPSec 会话，重新触发协商
plaintext
reset ike sa all
reset ipsec sa all

操作 2：查看 SA 状态，定位协商阶段
plaintext
# 查看一阶段IKE SA（有记录代表协商第一阶段成功）
display ike sa
# 查看二阶段IPSec SA（无输出=第二阶段协商失败，当前故障）
display ipsec sa

操作 3：ACL 流量命中统计
plaintext
display acl 3000

访问对端内网，若 ACL 命中计数不变 = 感兴趣流不匹配，重点修改 ACL 网段规则。
操作 4：查看 IPSec 加密统计，确认有无加解密报文
plaintext
display ipsec statistics

in/out 加密报文全 0 = 流量没有进入隧道，路由 / 免 NAT 配置错误。
操作 5：开启调试，抓取协商报错（精准定位参数不匹配）
plaintext
terminal monitor
terminal debugging
debugging ike verbose

复现访问流量，查看打印日志，会明确提示：算法不匹配、PFS 不一致、ACL 无匹配流量、NAT 拦截等报错。
八、高频坑点总结（MER5200 专用）
参数肉眼一致但 PFS 一端开一端关：界面默认隐藏 PFS 选项，极易漏看；
免 NAT 规则优先级低于普通上网 NAT：流量先匹配上网转换，导致 IPSec 失效；
静态路由下一跳写成公网网关，没有走 IPSec 隧道接口；
两端 SA 生存时间差值过大，协商成功后快速老化，状态瞬间清空；
运营商 / 上层防火墙拦截 UDP4500/ESP 报文，二阶段协商报文丢失；
内网 PC 网关不是 MER5200，跨三层交换机缺少回程明细路由。
九、修复后验证标准
display ipsec sa 能正常看到 inbound/outbound 两条 SA 记录；
display ipsec statistics 访问对端网段时，加解密报文计数持续增长；
内网 PC 双向 ping 对端业务网段，无丢包、长 ping 稳定；
隧道 Web 页面状态显示 “已连接”，不再为空。