为什么原生 Windows IKEv2 根本没有 PSK 字段

网关文档说预共享密钥要填在客户端里，但 Windows 配置文件根本没有这个字段。这个缺口不是靠把密钥敲进密码框就能绕过的缺陷。它体现的是协议能做到什么，与某个具体实现提供什么之间的差别。

协议能力不等于客户端支持

IKEv2 规范包含共享密钥认证，因此网关完全可以合法地为此配置。而原生 Windows 远程访问配置文件记录的是证书和 EAP 方案，协议能力并不会凭空造出客户端从来没有的字段、参数或注册表值。

人们通常会找到 添加 VPN 连接的 PowerShell 参考，那里为 L2TP 方案列出了 L2tpPsk。该参数属于 L2TP，不是通用的 IKEv2 机密。算法选择设置选择的是保护参数，这是第三件互不相关的事。Windows Server 的路由角色也不是同一个对象。服务器接口可能有桌面客户端配置文件没有的配置控制项，而把服务器设置复制到工作站配置文件里，并不能复现这种能力。

在证书、EAP 或 L2TP 之间选择

如果网关运营方接受证书认证，那通常是最干净的去向：客户端出示证书，网关向受信任的颁发者验证，配置文件中不会留下任何可被复制的共享机密。这需要注册、信任链，以及把证书映射到授权决定的网关配置。

使用用户凭据的 EAP 是这个客户端上另一条受支持的路径，它把决定交给身份提供方。它同样带来自己的依赖，因为 EAP 方法、服务器证书以及客户端对该证书的信任必须全部对齐。仅仅为了得到一个熟悉的字段就改用 L2TP/IPsec，会改变协议栈。当它是有文档记录理由的受支持选择时，这可以接受；当它发生是因为有人想找个框填密钥时，那就是糟糕的结果。

确认网关会接受什么

去问运营方，远程访问服务今天提供哪些认证方法，而不是产品一般支持哪些。只配置了 PSK 的 IKEv2 服务，不会因为客户端偏好证书就接受证书。

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

把配置文件的认证方法和证书存储放在一起读。设为 EAP 而背后没有可用证书的配置文件，失败起来很像服务器问题。

如果答案是只有 PSK 可用，诚实的选择是使用支持它的、经批准的客户端，或者改变网关的认证设计。两者都不是本地变通，假装是只会得到一条只有配置者本人才能复现的连接。

记录决定与机密

写下所选方法、信任锚、与之对应的身份，以及批准变更的人。这份记录正是事故复盘所需要的，也能阻止下一位工程师再次走进同一个死胡同。

在笔记里把机密分开：账户密码、私钥口令和网关预共享密钥是三件不同的事，即使设置界面把它们都叫密码。把它们混为一谈，密钥就会落进工单里。用一次全新连接和一次对私有资源的应用请求来测试生成的配置文件。隧道成功却访问不到任何服务，只是部分结果；在资源也能用之前，不应把配置文件说成完成。