msr3620点对点ipsec 野蛮模式过一阶段 main不可以

你遇到的主模式不通、野蛮模式可行的情况，核心原因在于IKE主模式（Main Mode）的协商机制存在一个关键限制：它无法穿越NAT设备。你的组网中，两端MSR3620大概率位于NAT设备（如防火墙）之后，因此主模式在NAT环境下失败是预期行为。

 根本原因：主模式为何无法穿越NAT？

IKEv1有两种协商模式，它们的报文交换过程不同：

• 主模式（Main Mode）：使用6个报文完成协商，其身份ID信息在加密后传输。

• 野蛮模式（Aggressive Mode）：使用3个报文完成协商，其身份ID信息在加密前明文传输。

关键区别在于：主模式在协商过程中，源端口号（UDP 500）可能被NAT设备修改。一旦端口被改变，后续的IKE报文就无法正确匹配到已建立的NAT会话，导致协商在第一阶段的Message 3/4处卡住或超时。而野蛮模式由于协商过程更快，且在NAT穿越（NAT-T）场景下有更好的兼容性，因此能成功建立。

你提到的“过一阶段 main不可以”，很可能就是指主模式在第一阶段（Phase 1）的Message 3或4处失败。

 主模式失败的常见原因与排查

如果你必须使用主模式（例如对端设备不支持野蛮模式），可以按照以下顺序排查：

1. 确认NAT环境与端口映射

• 检查两端MSR3620是否都位于NAT设备之后。如果是，必须在NAT设备上将UDP 500和UDP 4500端口映射到MSR3620的内网接口IP。缺少端口映射是主模式失败最常见的原因。

• 在MSR3620上执行 display ike sa verbose，观察主模式SA是否卡在 MM_SA_SETUP 或 MM_KEY_EXCH 状态。

2. 检查IKE身份标识（Identity）
主模式对身份ID的匹配比野蛮模式更严格。如果一端使用 identity address（IP地址），另一端使用 identity name（FQDN/域名），协商就会失败。建议两端统一使用 identity address，并确保地址与对端实际公网IP一致。执行 display ike proposal 和 display ike sa verbose 查看身份标识是否匹配。

3. 核对IKE提议（Proposal）参数
主模式对提议的协商顺序更敏感，必须确保两端加密算法、认证算法、DH Group完全一致。可以使用 display ike proposal 命令对比两端配置。

4. 检查预共享密钥（Pre-shared Key）
预共享密钥的匹配地址必须与对端身份标识一致。如果配置了 pre-shared-key address 1.1.1.2，但对端实际发送的身份ID是 1.1.1.2/16（带掩码），可能导致匹配失败。可以在 ike keychain 中尝试使用 pre-shared-key hostname 或匹配更宽泛的地址。

5. 确认软件版本兼容性
MSR3620的软件版本需支持标准IPsec，建议使用R67XX及以上版本。如果版本过旧，可能对某些IKE参数的处理存在差异。

现象：刚配置完主模式隧道可以正常起来；SA 老化重协商就失败；切野蛮模式一直正常可用。MSR3620 Comware‑V7 平台。

核心根因梳理

1. 存在 NAT 设备（中间防火墙 / 路由器做 NAT）【最高概率】 主模式 IKE 身份 ID 必须使用IP 地址类型；当中间有 NAT，NAT‑T 检测成功后切换 UDP4500 端口，主模式下身份 ID 仍然填写设备原始内网 IP，不是转换后的公网 IP，重协商身份校验直接失败； 野蛮模式可以使用 FQDN / 名称身份，不受 NAT 转换 IP 影响，所以一直正常H3C。

现象特征：第一次隧道手工触发可以 up；IKE SA 生命周期到期进行 rekey 重协商直接失败，流量断流；手工删除 ike‑sa 又可以短暂通一段时间。

2. IKE Profile 身份标识配置不匹配

• main 主模式：local‑identity默认是 IP 地址；要求两端 IKE profile 里面的身份必须是公网协商 IP；如果写成内网接口 IP，初次 SA 存在时流量还能跑，rekey 重协商校验身份直接失败。
• aggressive 野蛮模式常用 FQDN 身份，不受 IP 变化影响，不会出现该问题H3C。

3. DPD 对等体存活检测未开启 中间网络有会话老化，IKE 500/4500 报文被中间防火墙会话表清除；主模式重协商对身份校验严格更容易失败；野蛮模式容错性表现更好。
4. 版本 BUG：部分老版本 MSR3620 版本存在主模式 NAT‑T 重协商缺陷，升级固件可以修复。

快速定位排查命令

看 debug 日志，如果报错identity check failed，就是身份 ID 校验失败，确认是 NAT + 主模式身份问题。

三套解决方案（按推荐顺序）

方案 1：组网中间存在 NAT，优先改用野蛮模式（现场最常用）

只要路径上任意位置存在 NAT 转换，V7 不建议用 main 主模式，改用 aggressive 野蛮模式，身份用 FQDN。

注意 keychain 预共享密钥要匹配对端 FQDN 身份。

方案 2：坚持使用主模式 main（两端无任何 NAT，两端都是固定公网 IP）

只有两端网关直接公网对接，全程没有任何 NAT 设备，主模式才稳定。

1. IKE profile 不要手动修改 local‑identity，保持默认local‑identity ip‑address（使用对外公网 IP）；
2. 两端 ike‑profile 的身份都为 IP 地址类型；
3. 开启 DPD 检测，探测对端存活，防止中间设备会话老化。

方案 3：必须保留主模式，但中间有 NAT（不推荐，条件苛刻）

1. 上游 NAT 设备做端口静态映射 1:1，完整保留源 IP，不做 PAT 多对一转换；
2. MSR3620 升级到最新正式版本，规避已知 NAT‑T 主模式重协商 BUG；
3. 开启 DPD。

关键避坑要点

1. ✅主模式 main：身份 ID 只能是 IP 地址，不能 FQDN；遇到 NAT 环境重协商极易身份校验失败；
2. ✅野蛮模式 aggressive：支持 FQDN 身份，NAT 环境适配更好，适合有中间 NAT 的点对点；
3. ✅现象 “刚配置好能用，过一段时间不行” 几乎都是 IKE SA rekey 重协商阶段身份校验失败，不是 ACL、感兴趣流问题；感兴趣流问题是完全起不来隧道。
4. 不要靠 “手工删 ike‑sa 临时恢复业务”，治标不治本，到期复现。