Arm 版 Windows：VPN 驱动真的能加载吗？

安装程序运行，窗口打开，登录提示出现，于是迁移看起来已经完成。随后隧道在客户端需要虚拟适配器的那一刻失败，错误提到的是服务或驱动，而不是凭据。在 Arm 版 Windows 上，这个顺序很常见，因为兼容性规则在用户模式代码与内核模式代码之间发生了变化。批准一台笔记本需要第二次检查，而不是第一次。

问清整个软件包的架构，然后在机器上核实。

模拟无法覆盖的部分

只要仍处于用户模式，Arm 版 Windows 就能通过模拟运行 x86 和 x64 应用。内核模式组件得不到这种待遇：驱动必须为 Arm64 构建才能加载。微软记录了这条边界，而这正是 VPN 客户端通常所在的位置，因为它们中的许多会安装虚拟网络适配器或筛选器驱动。

因此，一个软件包可能呈现出可用的界面，却仍然无法使用。故障表现为适配器缺失、服务无法启动，或隧道始终无法建立。试点应当在这里停下。登录界面并不能证明数据通路可用。

决定迁移的三个条件

第一个是软件包。x64 构建和 Arm64 构建都叫 64 位，却并不通用，因此仅标注为 Windows 64 位的下载并不能证明任何与 Arm 设备有关的事情。厂商为该架构提供支持的安装程序，才是唯一可接受的起点。

第二个是其余必需组件。设备状态检查、浏览器辅助认证和智能卡中间件都可能各有自己的架构要求，而仅隧道成功并不能说明组织的访问策略已满足。

第三个是网关及其支持的客户端集合。如果获批客户端没有 Arm 构建，只有网关所有者支持该客户端的协议、认证方式和策略行为时，换用其他客户端才可以接受。Windows 内置 VPN 配置文件不能仅仅因为两者都被称为 IPsec 就替代专有客户端。

在设备上读取架构

确认机器是什么，然后查看软件包实际安装了哪些驱动。枚举只需一分钟，却能避免关于“64 位”含义的争论。

Get-CimInstance Win32_OperatingSystem | Select-Object OSArchitecture
$env:PROCESSOR_ARCHITECTURE
pnputil /enum-drivers | Select-String -Pattern 'vpn|tap|wintun' -Context 0,3
Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverProvider

如果适配器列表中看不到该客户端，或驱动条目报告架构不匹配，迁移就到此为止。把 Arm64 驱动放进旧容器并不是厂商支持的做法，兼容模式设置也不会转换 x64 内核驱动。

将已安装版本与厂商支持的 Arm 列表进行比较，如果安装程序来自内部仓库而非厂商，请记下差异。

批准工作负载，而不是登录界面

在保留上一台可用设备作为回退的前提下运行试点。核实配置文件下发、预期身份和任何设备检查，然后实际使用私有应用，而不只是看隧道状态。

覆盖私有 DNS、所需路由和地址族、网络变更后的重连，以及规定的断开状态。把客户端和组件版本与结果一起记录下来，因为下一次更新还会问同样的问题。

最后，确认该平台存在受支持的更新和卸载路径。只有在未记录替换之后才能工作的软件包，会在下一个版本制造同样的迁移问题，而解决时间更少。