Windows 与 FortiGate 上的 IKEv2：人们常合并的三项设置

Windows 客户端与 FortiGate 网关之间的一份 IKEv2 协议总是失败，而寻找不匹配的那个数字，只会给出更长的数字清单。只有当它被拆成三行各自独立失败时，这份清单才变得可管理：保护 IKE 的密钥交换、施加在 CHILD SA 上的保护，以及证明每一方是谁的认证。组号出现在其中两行里，含义各不相同。

各自独立失败的三行

第一行是 IKE 自身的密钥交换，它产生保护这次协商的密钥。第二行是 CHILD SA 的提议，它保护隧道承载的流量。第三行是认证，它决定每一方出示什么，以及另一方如何验证。

三类失败落在不同地方。交换失败会在任何隧道建立之前就中止协商。CHILD SA 失败发生在认证成功之后，有时只在换密钥时才出现。如果你只读第一条错误，认证失败在日志里看起来就像交换失败。

把行拆开不是为了记账。它改变了值得改动的是哪项设置，也挡住了这一整块里最昂贵的一步——为了修一处提议不匹配而重新签发还能用的证书。一行变化绝不该迫使另外两行跟着变。这种独立性，正是把它们分开写的全部意义。

Windows 的两个字段各管什么

Windows 把两个字段分开：DHGroup 配置 IKE 交换本身，而PfsGroup 配置保护隧道流量的 IPsec 策略。它们属于不同的阶段。把 Windows 的 IKE 字段去和 FortiGate 的 phase-2 值相比，是在测错误的一对，数字可能对得上，而底层交换照样失败。

Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

第二、第三条命令报告的是实际存在的安全关联，这是客户端能给你的最接近答案的东西。只有 main-mode 关联而没有 quick-mode 关联，就是 CHILD SA 问题，这是 phase-2 不匹配的签名，而不是证书问题。

把一次尝试里提出了什么、选中了什么记录下来。提供的列表里有可接受的提议，而选中的提议不符合网关策略，那是配置分歧，不是互操作的谜团。

椭圆曲线组并不挑选你的签名密钥

这一块里最顽固的错误推断，是认为选择椭圆曲线 DH 组就必须有椭圆曲线证书。DH 组提供密钥交换材料；签名算法由认证框架协商，在 IKEv2 里这是两个彼此独立的决定。

RFC 7427 之所以存在，正是因为这些决定过去缠在一起，它规定了签名算法如何独立于密钥交换来通告和选择。一个网关可以同时支持曲线组和一组签名方案的选择。

所以当换组之后协商失败时，先看认证方法，再看证书的密钥类型。换证书是一个缓慢、有风险的操作，很少是答案，而先做它，会毁掉你判断究竟是哪项改动起了作用的能力。在碰证书库之前，先读认证那一行。

把两者分开放在协议表的不同行里，这个错误就不再诱人。一行列组，另一行列签名方案与身份，谁都不是对方的证据。

把每把私钥交给它真正的主人

出示自己证书的网关需要与之匹配的私钥。验证证书链的对端需要 CA 证书，而且特别不需要 CA 的签名密钥。把这三样东西搞混，正是有人把 CA 私钥导入 VPN 设备、好让某张证书出现在另一个类别里的由来。

在 FortiOS 上，角色是分开的：带密钥的本地证书、用来标识对端的远程证书，以及为那个 CA 签发的证书建立信任的远程 CA 条目。没有私钥的远程 CA 条目并不残缺；它对自身用途而言是正确的。

导入的 CA 签名密钥会扩大任何能读取那台设备的人的权限。它们也解决不了普通的对端验证，因为验证需要公开证书和信任决定，而不是签发新证书的能力。

把 CA 签名密钥留在签发方自己的流程里，并记录哪台设备持有哪把密钥。当审计问起谁可以冒充谁时，一张简短的持有者表比一张更长的算法表更有价值。没有人会导入一把自己知道只是库存的密钥。把清单写在事故之前，而不是之后。