H3C 与深信服 IPsec 排障实录：从 Unknown 到 RD 作者: zhaoyang 更新: 2026年09月10日 1,841 字 约 6 分钟阅读 分类: 系统运维 8 月 31 日，我开始尝试配置 H3C 与深信服之间的 IPsec，实现分支与总部内网互通，当天未确认业务调通。9 月 9 日，我继续排查，借助 H3C 命令行定位到 HASH 认证失败，删除并重建 hostname 预共享密钥条目后，隧道恢复。 <!--more--> > 地址、网段、身份 ID 和策略名均已脱敏。命令中的 `<…>` 是占位符，使用前须整体替换；真实密码和密文不随文发布。 ## 1. 8 月 31 日：开始配置两端 IPsec 分支使用 H3C 防火墙拨号上网，总部使用深信服防火墙固定公网接入。当天，我登录两台设备的 Web 管理界面，开始配置两端 IPsec。环境与配置关系如下： | 项目 | 分支 H3C | 总部深信服 | | --- | --- | --- | | 设备与版本 | F1000-AI-25，Comware 7.1.064 R8860P18 | AF，8.0.95 | | 公网接入 | Dialer0，PPPoE 获取公网地址 | eth5，固定公网地址 | | 协商角色 | 自动发起连接 | 接收分支连接 | | 身份 ID（调整后） | USER_FQDN：BRANCH-VPN | USER_FQDN：HQ-VPN | | 保护网段 | 10.60.0.0/16 | 10.20.0.0/16 至 10.24.0.0/16，共五组 | 最初配置时，固定公网一侧使用 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 查询： ```text display ike sa display ipsec sa ``` 当时两张 SA 表均无有效条目。这只说明查询时没有 SA，不能据此认定设备从未协商过。 ### 补充地址匹配密钥后，出现 Unknown 检查 H3C 完整配置，发现目标 keychain 只有 hostname 密钥条目： ```text 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 配置案例](https://knowledge.h3c.com/Theme/details/106739) ```text 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 命令说明](https://www.h3c.com/cn/d_202608/2902550_30005_0.htm) 随后 IKE 表出现对端，但状态为 `Unknown`，IPsec SA 仍为空。补充地址匹配项没有完成修复；修改前也没有采集到“找不到密钥”的调试记录，因此不能把缺少 address 条目认定为全部故障原因。 ## 3. 两端日志将失败点指向 HASH 认证 深信服 VPN 日志显示，它已收到分支请求，并根据 `USER_FQDN:BRANCH-VPN` 选中目标连接配置。随后反复出现 INFO 报文异常、message ID 不能为 0，以及校验失败和重传提示。 这些信息证明请求到达，却不足以认定两家设备不兼容。我转到 H3C 用户视图，短时开启 IKE 调试： ```text terminal monitor terminal debugging debugging ike error debugging ike event ``` 利用自动协商重试，我获得了关键日志。以下省略时间戳等字段，并替换了名称： ```text 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 条目仍参与了这轮认证。 采集后关闭调试： ```text undo debugging ike error undo debugging ike event undo terminal debugging undo terminal monitor ``` 至此，失败点已明确，但 HASH 失败本身还不能证明是我输错了密码。 ## 4. 直接覆盖被拒，删除重建后恢复 我在深信服重新输入并保存原先约定的 PSK，同时尝试更新 H3C 的 hostname 密钥。隧道仍然是 `Unknown`。 检查命令返回，发现设备没有接受直接覆盖： ```text A pre-shared key has already been configured for host HQ-VPN. ``` **这次修改没有生效，旧条目仍然保留。** 此后即使执行 `save`，保存的也只是设备已经接受的配置。 我改为先删除 hostname 条目，再复制同一台 H3C 上 address 条目的完整密文重新添加。以下从用户视图开始： ```text 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 入口能否提供同等信息，未作验证。 这次排障留下的经验是：核对配置以后，还要检查实际匹配结果；修改以后，要确认设备接受了命令，再回读配置、验证状态。找到有效的恢复操作，与查清最初故障成因，是两件需要分别确认的事。 标签: IPsec, VPN排障, H3C, 深信服, IKE, 预共享密钥