H3C 与深信服 IPsec 排障实录：从 Unknown 到 RD

8 月 31 日，我开始尝试配置 H3C 与深信服之间的 IPsec，实现分支与总部内网互通，当天未确认业务调通。9 月 9 日，我继续排查，借助 H3C 命令行定位到 HASH 认证失败，删除并重建 hostname 预共享密钥条目后，隧道恢复。

地址、网段、身份 ID 和策略名均已脱敏。命令中的 <…> 是占位符，使用前须整体替换；真实密码和密文不随文发布。

1. 8 月 31 日：开始配置两端 IPsec

分支使用 H3C 防火墙拨号上网，总部使用深信服防火墙固定公网接入。当天，我登录两台设备的 Web 管理界面，开始配置两端 IPsec。环境与配置关系如下：

最初配置时，固定公网一侧使用 IP 身份，动态公网一侧使用 USER_FQDN，后来改成两侧均使用 USER_FQDN。这期间，我约定使用的 PSK 始终没有改变。

当天 09:37:49，深信服目标连接的日志记录了 host changed, disconnect sa，随后记录配置生效、旧 SA 删除，以及第一阶段和五组第二阶段连接的删除通知。日志中的对端地址与当时 H3C 拨号接口一致。

这些记录提示可能短暂建立过 SA，但不足以证明业务已经互通；host changed 也没有指出具体变更了哪个字段。当天的调试没有完成业务互通验证，问题留待继续排查。

2. 9 月 9 日：继续排查，确认当前没有 SA

9 月 9 日，我重新登录两端防火墙，核对身份对应关系、保护网段、出口绑定、安全策略和 NAT 豁免，没有发现能直接解释当前故障的明显差异。

此时核对的参数为：IKEv1 野蛮模式、PSK、AES-256、SHA-256、DH14，IKE 生存时间 86400 秒；第二阶段使用 ESP 隧道模式、AES-256、SHA-1，不启用 PFS。

随后在 H3C 查询：

display ike sa
display ipsec sa

当时两张 SA 表均无有效条目。这只说明查询时没有 SA，不能据此认定设备从未协商过。

补充地址匹配密钥后，出现 Unknown

检查 H3C 完整配置，发现目标 keychain 只有 hostname 密钥条目：

ike keychain VPN_BRANCH_HQ
 match local address Dialer0
 pre-shared-key hostname HQ-VPN key cipher <原有密文>

IPsec 策略则主动连接总部固定地址 203.0.113.20。参考 H3C 关于主动端密钥地址匹配的配置说明，我在同一 keychain 下补充 address 条目。H3C 配置案例

pre-shared-key address 203.0.113.20 255.255.255.255 key simple <与总部一致的PSK>

这里曾把明文密码接在 key cipher 后，设备返回 Invalid ciphertext key。改用 key simple 才添加成功：simple 接收明文，cipher 接收设备可识别的密文。H3C 命令说明

随后 IKE 表出现对端，但状态为 Unknown，IPsec SA 仍为空。补充地址匹配项没有完成修复；修改前也没有采集到“找不到密钥”的调试记录，因此不能把缺少 address 条目认定为全部故障原因。

3. 两端日志将失败点指向 HASH 认证

深信服 VPN 日志显示，它已收到分支请求，并根据 USER_FQDN:BRANCH-VPN 选中目标连接配置。随后反复出现 INFO 报文异常、message ID 不能为 0，以及校验失败和重传提示。

这些信息证明请求到达，却不足以认定两家设备不兼容。我转到 H3C 用户视图，短时开启 IKE 调试：

terminal monitor
terminal debugging
debugging ike error
debugging ike event

利用自动协商重试，我获得了关键日志。以下省略时间戳等字段，并替换了名称：

Received packet successfully.
Found pre-shared key in keychain VPN_BRANCH_HQ matching name HQ-VPN.
Oakley transform 1 is acceptable.
Failed to verify the peer HASH.

H3C 已收到报文，接受了当前 IKE 提议，并选中了 hostname 条目对应的密钥，随后 HASH 校验失败。即使已经补充 address 条目，hostname 条目仍参与了这轮认证。

采集后关闭调试：

undo debugging ike error
undo debugging ike event
undo terminal debugging
undo terminal monitor

至此，失败点已明确，但 HASH 失败本身还不能证明是我输错了密码。

4. 直接覆盖被拒，删除重建后恢复

我在深信服重新输入并保存原先约定的 PSK，同时尝试更新 H3C 的 hostname 密钥。隧道仍然是 Unknown。

检查命令返回，发现设备没有接受直接覆盖：

A pre-shared key has already been configured for host HQ-VPN.

这次修改没有生效，旧条目仍然保留。 此后即使执行 save，保存的也只是设备已经接受的配置。

我改为先删除 hostname 条目，再复制同一台 H3C 上 address 条目的完整密文重新添加。以下从用户视图开始：

system-view
ike keychain VPN_BRANCH_HQ
undo pre-shared-key hostname HQ-VPN
pre-shared-key hostname HQ-VPN key cipher <ADDRESS条目的完整密文>
display this
quit
quit

display this 确认 address 与 hostname 两项使用同一份密文。这次没有再被拒绝，也没有修改身份、算法或重置全部 SA。自动重试后：

• H3C 的 IKE 状态从 Unknown 变成 RD。
• IPsec 表出现入站、出站 ESP SA，使用 AES-256 / SHA-1。
• 深信服运行状态显示目标连接“正常”，五组保护网段均有双向 SPI。

这些结果确认了 IKE 和 IPsec SA 已建立。修复后还应在用户视图执行 save，并从内网主机验证实际业务；SA 建立不能替代业务测试。

5. 结论：确认了修复方法，最初成因仍未查明

这次能确认的过程是：

选中 hostname 密钥 → HASH 认证失败 → 直接覆盖被拒 → 删除重建 → 协商恢复。

身份 ID、密钥匹配条件和 PSK 内容是不同的配置项。同一个约定密码可能存在于不同条目中，因此需要检查设备实际选用了什么。但重建成功并不能反推旧条目的明文一定不同，也不能证明 Web 存在已知缺陷。

目前没有各次 Web 提交前后的完整配置差异和对应日志，无法确定最初异常来自密钥内容、条目关联还是运行状态。CLI 的覆盖拒绝只解释了那次修复为何未生效，不能倒推此前 Web 保存也发生了同样的问题。

修复后，我检查了 Web“IPsec 诊断”及导出的 Excel，只有接口、策略绑定、待加密流、策略完整性、IKE SA 和 IPsec 隧道六项摘要，没有展示密钥选择和 HASH 校验过程。仅靠这份摘要，定位不到本次具体失败点。 本次命令行提供了所需的详细配置与日志；其他 Web 入口能否提供同等信息，未作验证。

这次排障留下的经验是：核对配置以后，还要检查实际匹配结果；修改以后，要确认设备接受了命令，再回读配置、验证状态。找到有效的恢复操作，与查清最初故障成因，是两件需要分别确认的事。