为什么先做参数表
两个不同厂商的设备要建 IPsec 隧道，失败原因十有八九是参数没对齐，而不是设备有缺陷。参数表的思路是把「协商需要一致的每一格」提前列出来，双方在配置前逐格填好并互相确认：IKE 版本、加密算法、完整性算法、DH 组、身份类型、生存期、PFS 与流量选择符。有了这张表，联调时不是盲试，而是拿报错对照表中某一格。经验做法是把表写在交付文档里，作为隧道资产的一部分存档，后续换设备或改参数时直接从表出发，不必重新摸索。
基本信息
| IKE 版本 | IKEv1 或 IKEv2，必须先定，不能两端各写一个 |
|---|---|
| 阶段一 | 加密、完整性/PRF、DH 组、生存期、身份类型 |
| 阶段二 | ESP 算法、模式、PFS 开关与 DH 组、生存期 |
| 流量选择符 | ACL 或网段列表，必须互为镜像 |
| 认证方式 | PSK 或证书，证书还需对齐身份标识 |
| 记录方式 | 写入交付文档，变更时同步更新 |
典型使用场景
- 跨厂商首次联调：把表发给对方确认后再各自配置
- 集团与分支机构对接：总部统一出表，分支照表配置
- 隧道改造：换设备或升级版本前先确认表内各项是否仍被支持
- 故障复盘：把实际协商结果回填到表内，形成对照基线
- 多隧道管理：同类型隧道共用一张模板表，减少重复沟通
填表与核对
填表与核对
# 逐项核对本端实际生效的参数
show crypto ikev2 proposal
show crypto ipsec transform-set
show crypto isakmp policy
# IKEv2 profile 中的身份与认证方式
show crypto ikev2 profile P1
# 确认协议中实际协商出的提议
show crypto ikev2 sa detail
# 华为侧对照
display ipsec proposal参数对照表样例
| 参数项 | 本端 | 对端 |
|---|---|---|
| IKE 版本 | IKEv2 | IKEv2 |
| 加密算法 | AES-256-CBC | AES-256-CBC |
| 完整性算法 | SHA2-256 | SHA2-256 |
| PRF | SHA2-256 | SHA2-256 |
| DH 组 | group14 | group14 |
| ESP 与 PFS | AES-256-SHA256，PFS group14 | AES-256-SHA256，PFS group14 |
| 生存期 | 阶段一 86400 秒，阶段二 3600 秒 | 同左 |
表中每一项都要写实际值而不是「默认」：不同平台的默认值并不相同，联调现场才发现差异是常见误工原因。
IKEv1 阶段一的交换模式（主模式或野蛮模式）也需列入表中：动态地址一侧常用野蛮模式，两端不一致时协商不会成功。