Windows 的 IKEv2 自定义策略：把它当作独立步骤来落实

已预配的连接和自定义密码套件是两个结果。把策略字段、配置文件作用域以及重新施加这些设置的负责人对齐。

预配包会创建一个 IKEv2 连接，而由此生成的配置文件所协商的算法套件，往往并不是你预期的那个。预配包只完成了它自身的工作，它从来没有为你想当然的那项任务提供字段。请把密码套件当作一个独立且可验证的预配步骤。

按顺序完成下面五项，并把验收结果分开记录。

名称相似背后的两类策略

Windows 把保护密钥交换的策略与保护流量的策略分开。IKE 一侧由加密方法和完整性方法来配置。数据一侧由密码算法和认证转换常量来配置，而这些常量使用它们自己的名称。只要把一个 AES 标签复制到错误的字段，就会得到一条按照无人批准的策略建立的连接。

密钥交换组和完全向前保密属于同一次协商，并且必须为网关所接受。在不检查远端的情况下设置它们，失败会出现在比你正在编辑的那一步更靠后的阶段，这正是这类错误看起来像网关问题的原因。

构建完整策略，而不是两个算法名称

把每个字段都显式写出来，包括那些你认为是默认值的字段。用强制标志应用的部分策略会成为保存下来的配置，而你省略的取值就是平台在那一刻碰巧拥有的值。前缀相同的取值不能跨字段互换，而其中一个常见转换名称只在作为认证转换时才有效。

$policy = @{
    ConnectionName = 'Corp IKEv2'
    AllUserConnection = $true
    EncryptionMethod = 'AES256'
    IntegrityCheckMethod = 'SHA384'
    CipherTransformConstants = 'AES256'
    AuthenticationTransformConstants = 'SHA384128'
    DHGroup = 'Group19'
    PfsGroup = 'PFS2048'
    Force = $true
}
Set-VpnConnectionIPsecConfiguration @policy

把那个代码块当作双方都必须支持的示例套件，而不是推荐配置。强制开关只是抑制提示，它不会为你没有审阅过的预配包背书。

先创建，再应用——在同一作用域内

必须先存在连接，才能设置它的策略，而且每一步的作用域都必须一致。机器上下文的步骤不能仅仅因为显示名称相同，就找到某个用户的专用配置文件。所有用户连接、用户连接及其状态目录是名称各不相同的独立对象。

在预配包里，顺序比看起来更重要，因为两条命令之间的间隔可能比创建连接所需的时间还短。应把配置后的工作打包成一条声明了执行上下文的、已批准的预配命令，让预配引擎去排序，而不是插入一个凭经验猜测的延时。在测试硬件上足够长的等待，本质上就是带延时的竞态条件。应记录依赖关系，而不是记录时长。

文档中列出的 Configuration Designer 字段只描述某一项 VPN 设置，并没有暴露 IPsec 的全部原生控制项。如果要求是受管交付，VPNv2 配置服务提供程序里正好有密码套件一节。

为策略指定唯一的负责人

后续的管理配置文件更新可能重建连接，并替换掉脚本所应用的设置，这看起来就像一次功能回退。请决定套件归配置文件、归脚本还是归管理通道所有，并让例行更新走与首次安装相同的路径。

当两个负责人意见不一致时，有两个负责人等于没有。把负责人的名字写进配置文件的变更记录。下一次更新会按照那条记录执行。

验证协商结果，而不是预配包

读取已保存的配置文件及其作用域，然后建立一条新连接，并在网关上比较所选的提案。还要确认重新生成密钥的行为，因为初次握手可能用上某个后续阶段会拒绝的套件。

Get-VpnConnection -Name 'Corp IKEv2' -AllUserConnection | Format-List
Get-ChildItem 'C:\ProgramData\Microsoft\Network\Connections\Pbk' | Select-Object Name, LastWriteTime

三个验收结果并不是同一件事：预配包安装成功、配置文件带着预期策略存在、双方实际协商成功。请把它们分开，这样缺失的字段就永远不会靠削弱认证或启用没人选择的回退方案来修复。

相关文章