IKEv1 的混合认证如何过渡到 IKEv2 的用户认证

每个要求先提供服务器证书、再要求用户名的旧 VPN 配置，都在一次交换里承载两个认证事件，而这种形态比引入它的协议活得更久。IKEv1 的混合模式正是为此而生：网关用公钥证明自己，用户随后通过 XAuth 证明自己。IKEv2 用另一套机制表达同样的两步思路，迁移恰恰在这些差异上失败。没有任何版本号能把两者互相转换，而把旧选项名复制到新配置里，只会得到一个能协商却什么都认证不了的客户端。

混合模式在 IKEv1 内部做了什么

在混合配置中，响应方用自身证书对第一阶段的交换签名，而发起方刻意不出示任何证书。身份证明因此是不对称的，这正是网关得以保留现有 PKI、而用户继续使用目录口令的原因。第一阶段完成后，XAuth 以请求和应答的形式运行，在已经加密的 ISAKMP 通道内携带用户名和口令属性。

注意信任落在哪里。证书回答客户端到达的是哪一台网关；XAuth 回答是哪个用户想要接入。两者不能互相替代，而一个被配置为接受任意服务器证书的客户端，已经悄悄丢掉了第一个答案。混合这个标签也被用于带预共享密钥的积极模式加 XAuth，那是一种用户体验相同但结构不同的安排，所以要读配置而不是读名字。两种变体都源自从未成为标准的草案，这就是为什么两家厂商都能实现混合模式，却彼此无法互通。

IKEv2 如何达到同样的两个证明

IKEv2 把工作分到 IKE_SA_INIT 和 IKE_AUTH 两个交换里。第一个交换完全不涉及身份，只商定提议和密钥；第二个交换承载 IDi、IDr 和 AUTH 载荷。在 EAP 之下，发起方的第一个 AUTH 载荷是空的，响应方先用证书和签名完成认证，随后 EAP 对话在 IKE_AUTH 消息内部进行。

让这一切安全的机制是密钥材料。成功的 EAP 方法会导出会话密钥，发起方最终的 AUTH 载荷由它计算，因此用户的证明与隧道密钥绑定在一起。XAuth 没有等价物：它的属性在第一阶段之后才到达，对密钥没有任何贡献。这正是 IKEv2 框架要补上的缺口，也是为什么一次能用的 IKEv2 登录会在提示任何输入之前先校验服务器证书。

这个顺序也是有用的诊断。当客户端还未向你展示证书就先抱怨凭据不对，它根本没有在做 IKEv2 的 EAP 交换。

把三种身份分开

当三种身份塌缩成一个字段时，迁移就会出错。这里有客户端所校验的网关身份，通常是证书 subject 或 SAN 中的 DNS 名称。这里有在 EAP 中呈现的用户身份，可能是域登录、地址或显式的 EAP 身份字符串。还有把该用户映射到网络和路由的授权来源。

strongSwan 的 swanctl 语法把这种区分显示出来：连接为网关设置 remote { auth = pubkey }，为用户设置 local { auth = eap-mschapv2 }，而 EAP 身份单独传递。

当新配置中的用户身份与旧的 XAuth 属性不同时，例如用 UPN 而不是短名，认证服务器看到的是未知用户，失败看起来就像密码错误。请在核对凭据之前先核对身份字符串。

把选项映射清楚，然后预期陷阱

映射很短，而每一行都有一个只在认证时才出现的陷阱。

这些行没有一行只是改名。配置载荷通过带类型的属性列表下发地址和解析器，而 XAuth 的属性空间是它自己的发明；把它们当作可以互换，正是一份配置最后去要求网关永远不会发送的设置的原因。

流量选择器值得单独警告。IKEv1 用绑定到快速模式交换的代理 ID 来表达感兴趣的流量，而 IKEv2 在 IKE_AUTH 期间协商选择器，响应方还可能把它们收窄。不匹配会产生一个已建立却没有子 SA 的 IKE SA，而有些客户端会高高兴兴地把它显示为已连接。

把旧连接当作边界

RFC 9395 已把 IKEv1 列为过时，所以旧的混合连接是一条带日期的兼容边界，而不是地基。在变更期间并行运行两套配置，因为真正重要的测试不是新配置能否起来，而是同一个用户在同一台设备上能否到达同样的资源。

全程保持严格的证书校验。一旦客户端不再出示自己的证书，人就会想放宽服务器校验直到握手完成，而那是用仅剩的证明去换一个绿色图标。

在退役旧配置之前写下四件事：EAP 方法、身份字符串、授权来源，以及支持结束的日期。