在混合办公和零信任安全大行其道的今天,企业对远程访问的可靠性要求越来越高——说实话,VPN 一旦出问题,不管是用户投诉还是业务中断,都会让 IT 团队焦头烂额。Windows Always On VPN(简称 AOVPN)凭借自动连接、无缝切换和精细策略控制等优势,正在成为替代传统 VPN 和 DirectAccess 的主流方案。本指南覆盖从环境准备、Intune 部署,到常见故障排查、2026 年最新安全漏洞修复的完整流程,帮助企业 IT 管理员快速建立稳定可靠的远程访问基础设施。
企业 Windows Always On VPN (AOVPN) 部署与故障排除完全指南(2026)
通过 Intune 部署企业 Windows AOVPN,解决 0x800B0109、13806 等故障,处置 CVE-2026-33824 高危漏洞(CVSS 9.8),涵盖 PowerShell 诊断、证书配置与 Windows 11 26H1 PEAP Bug 规避方案。

Always On VPN 是微软在 Windows 10/11 企业版中引入的新一代远程访问解决方案,支持两种独立的隧道模式:
- 设备隧道(Device Tunnel):在用户登录前自动建立,使用计算机证书进行 IKEv2 认证,专为域加入设备设计,支持 Windows Autopilot 和开机后立即访问域控。仅 Windows Enterprise / Education 版本支持。
- 用户隧道(User Tunnel):用户登录后自动建立,使用用户证书或 PEAP 认证,适用于所有 Windows 10/11 版本,是大多数企业远程访问场景的主力模式。
一句话总结:设备隧道给机器用,用户隧道给人用。绝大多数企业只需要部署用户隧道就能覆盖 90% 的远程访问需求。与 DirectAccess 相比,AOVPN 不依赖 IPv6 和 ISATAP/Teredo 过渡技术,支持 IKEv2、SSTP 和 L2TP 多种协议,可与 Microsoft Intune 和 Microsoft Entra ID(原 Azure AD)深度集成,是微软官方指定的 DirectAccess 长期替代方案。
前提条件与环境准备
基础设施要求
- Windows Server 2019 或更高版本的 RRAS(路由和远程访问服务)服务器,建议 2022 以获取最新安全补丁
- 网络策略服务器(NPS)用于 RADIUS 认证,需在内网中高可用部署
- 内部 PKI(企业 CA)签发用户和设备证书,推荐使用 Microsoft ADCS + NDES
- Microsoft Intune + Microsoft Entra ID(混合加入或纯 Entra 加入均可)
- 客户端:Windows 10 1903+ 或 Windows 11(设备隧道需要 Enterprise / Education 版本)
- VPN 服务器对外开放的端口:UDP 500(IKE)、UDP 4500(IKE NAT-T)、TCP 443(SSTP)
IKEv2 证书要求(设备隧道关键前提)
IKEv2 是 AOVPN 设备隧道的唯一支持协议,对证书配置有严格要求。坦率地说,这里是大多数首次部署 AOVPN 的团队踩坑最多的地方——任何一点偏差都可能导致连接失败,而且报错信息往往不够直观:
- VPN 服务器证书必须同时包含两个 EKU:Server Authentication(OID 1.3.6.1.5.5.7.3.1)和 IP security IKE intermediate(OID 1.3.6.1.5.5.8.2.2)
- 证书的 CN 或 SAN 必须与 VPN 客户端连接时使用的服务器 FQDN 完全匹配(例如
vpn.corp.example.com) - 服务器证书必须安装在 Local Computer → Personal 证书存储中(不是用户存储)
- 签发机构的根证书必须存在于所有客户端的 Trusted Root Certification Authorities 存储中
通过 Microsoft Intune 部署 AOVPN
通过 Intune 部署 AOVPN 需要按顺序创建三个配置文件,并全部分配给同一 Entra ID 用户组(或设备组)。在进行 Intune 策略部署之前,建议先了解 Windows LAPS Intune 部署与故障排除完全指南 中关于配置文件创建顺序和分配策略的通用最佳实践,两者流程高度相似。
步骤一:创建受信任根证书配置文件
- 登录 Intune 管理中心(intune.microsoft.com),导航至 设备 → 配置 → 创建配置文件
- 平台选择 Windows 10 及更高版本,配置文件类型选择 受信任的证书
- 上传企业根 CA 证书(.cer 或 .crt 格式),目标存储选择 计算机证书存储 - 根
- 将配置文件分配给 VPN 用户组,等待策略同步(通常 15–30 分钟)
步骤二:创建 SCEP 证书配置文件
- 创建新配置文件,类型选择 SCEP 证书
- 证书类型:用户隧道选 用户,设备隧道选 设备
- 主题名称格式:用户证书用
CN={{UserPrincipalName}},设备证书用CN={{DeviceName}} - 扩展密钥用法(EKU)至少包含 客户端身份验证
- SCEP 服务器 URL 指向 NDES(网络设备注册服务)端点:
https://ndes.corp.example.com/certsrv/mscep/mscep.dll - 重要:此配置文件的依赖配置文件必须设置为步骤一创建的根证书配置文件
步骤三:创建 VPN 配置文件(ProfileXML 方式)
对于完整的 AOVPN 自定义配置,使用 自定义配置(OMA-URI) 方式推送 ProfileXML 是业界标准做法(内置 VPN 模板的选项太少,复杂场景根本不够用)。以下为用户隧道的典型配置示例:
<VPNProfile>
<DnsSuffix>corp.example.com</DnsSuffix>
<NativeProfile>
<Servers>vpn.corp.example.com</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<UserMethod>Eap</UserMethod>
<Eap>
<Configuration>
<!-- EAP-TLS 配置(推荐,安全性高于 PEAP) -->
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<EapMethod>
<Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type>
</EapMethod>
</EapHostConfig>
</Configuration>
</Eap>
</Authentication>
<RoutingPolicyType>SplitTunnel</RoutingPolicyType>
</NativeProfile>
<AlwaysOn>true</AlwaysOn>
<RememberCredentials>true</RememberCredentials>
<TrustedNetworkDetection>corp.example.com</TrustedNetworkDetection>
<DomainNameInformationList>
<DomainNameInformation>
<DomainName>.corp.example.com</DomainName>
<DnsServers>10.0.0.1,10.0.0.2</DnsServers>
</DomainNameInformation>
</DomainNameInformationList>
</VPNProfile>
OMA-URI 路径(用户隧道):
./User/Vendor/MSFT/VPNv2/<VPN连接名称>/ProfileXML
OMA-URI 路径(设备隧道):
./Device/Vendor/MSFT/VPNv2/<VPN连接名称>/ProfileXML
步骤四:验证部署状态
在测试设备上以 VPN 用户身份登录,打开 设置 → 账户 → 访问工作或学校账户,选择账户后点击 信息 → 同步 强制触发 Intune 策略同步。成功后,VPN 连接将出现在 设置 → 网络和 Internet → VPN 中,并自动建立连接。
小技巧:如果策略迟迟不同步,可以在 Intune 管理中心手动触发"设备签入",通常比等待自动同步快得多。
常见错误代码与修复方法
AOVPN 连接失败通常有迹可循。以下是 2026 年企业环境中出现频率最高的错误代码及其根本原因与修复步骤——相信我,这些坑大多数人都踩过。
错误 0x800B0109 — 证书链不受信任(CERT_E_UNTRUSTEDROOT)
含义:客户端无法验证 VPN 服务器提供的证书链,根证书不在受信任存储中。(这可能是 AOVPN 部署中最常见的首次故障,几乎每个第一次部署的团队都会遇到。)
常见根本原因:
- 客户端的 Trusted Root Certification Authorities 存储缺少企业根 CA 证书(多见于非域加入设备)
- VPN 服务器证书 CN/SAN 与连接地址不匹配
- 服务器证书缺少 IP security IKE intermediate EKU(OID 1.3.6.1.5.5.8.2.2)
- 证书已过期或被吊销
修复步骤:
在 VPN 服务器上运行以下命令验证证书配置:
# 查看 VPN 服务器 Personal 存储中的证书及其 EKU
Get-ChildItem Cert:\LocalMachine\My |
Select-Object Subject, NotAfter,
@{N="EKU";E={$_.EnhancedKeyUsageList.FriendlyName -join ", "}} |
Format-Table -AutoSize
确认输出中包含 Server Authentication 和 IP security IKE intermediate。如果证书缺少 IKE EKU,需要重新从企业 CA 申请证书,并在证书模板中添加该 EKU。通过 Intune 的受信任根证书配置文件将根 CA 推送到所有托管设备。
错误 13806 — IKE 找不到有效的计算机证书
设备隧道连接时,事件查看器显示 Error 13806: IKE failed to find a valid machine certificate。
- 确认设备证书已部署到 Local Computer → Personal 证书存储(非用户存储)
- 检查 Intune 管理中心中 SCEP 配置文件的设备状态是否显示"成功"
- 在 Intune 中验证设备组分配是否包含该设备
- 在设备上运行以下命令确认计算机证书存在:
Get-ChildItem Cert:\LocalMachine\My |
Where-Object {$_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"} |
Select-Object Subject, NotAfter
错误 812 — 身份验证方法不匹配
NPS 服务器策略配置的身份验证方法与 VPN 配置文件中的 EAP 类型不一致。
- 在 NPS 服务器打开 网络策略 → 约束 → 身份验证方法,确认已勾选 EAP-TLS 或 PEAP(与客户端配置一致)
- 确认 NPS 策略的"加密强度"设置与 ProfileXML 中的 EAP 配置匹配
- 查看 NPS 事件日志(事件 ID 6273)获取认证失败的详细原因
错误 720 / 事件 ID 20227 — WAN Miniport 适配器未绑定
此错误通常在系统更新后出现,WAN Miniport (IP) 适配器绑定丢失。运行以下命令重置:
# 以管理员身份运行 PowerShell
$adapters = Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*WAN Miniport*"}
foreach ($adapter in $adapters) {
Disable-NetAdapter -Name $adapter.Name -Confirm:$false
Start-Sleep -Seconds 2
Enable-NetAdapter -Name $adapter.Name -Confirm:$false
}
# 若仍无效,重置 TCP/IP 和 Winsock
netsh int ip reset
netsh winsock reset
# 重启后再次测试
错误 787 — L2TP/IPSec SA 建立失败
常见于 VPN 服务器使用通配符证书,或客户端与服务器使用来自不同 CA 的证书。强烈建议将协议从 L2TP 切换至 IKEv2 以获得更好的安全性和兼容性。如需继续使用 L2TP,确保两端使用来自同一 CA 的有效证书。
⚠️ 2026 年重大安全漏洞:CVE-2026-33824(CVSS 9.8 严重)
微软于 2026 年 4 月披露了一个影响 Windows IKE 服务扩展的严重远程代码执行漏洞,CVE-2026-33824 的 CVSS 3.1 基础评分高达 9.8(严重),无需用户交互即可被远程利用。CVSS 9.8 是什么概念?可以说是最高级别的威胁了,暴露在公网的 RRAS 服务器如果不立刻打补丁,后果不堪设想。
影响范围:
- 所有使用 IKEv2 用户隧道的 Always On VPN 部署
- 所有 Always On VPN 设备隧道(设备隧道强制使用 IKEv2,无法规避)
- RRAS 服务器运行的所有受支持 Windows Server 版本
立即行动步骤:
- 通过 Windows Update 或 WSUS 向所有 RRAS 服务器部署 2026 年 4 月安全累积更新
- 验证补丁状态:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15 |
Format-Table HotFixID, InstalledOn, Description
- 如业务允许临时停用 IKEv2,改用 SSTP 协议降低攻击面(注意:这会中断所有设备隧道):
# 在 RRAS 服务器上执行(需重启 RemoteAccess 服务)
Set-VpnServerConfiguration -TunnelType Sstp
Restart-Service RemoteAccess -Force
- 在 RRAS 服务器防火墙上限制 UDP 500/4500 的来源 IP 范围,降低暴露面
- 持续监控 RRAS 服务器安全事件日志,关注事件 ID 20250–20280 范围内的异常
Windows 11 26H1 的 PEAP 认证 Bug
2026 年 4 月,专注于 Always On VPN 的安全研究员 Richard M. Hicks 记录了 Windows 11 26H1 中的一个严重 Bug:凡是使用 PEAP(受保护的可扩展认证协议) 的 VPN 连接,无论是 Always On VPN 还是手动 VPN,所有连接尝试均会失败。这个 Bug 在没有提前预警的情况下影响了不少企业环境,很多 IT 团队在 26H1 推送后才发现问题,花了好几天才定位到根源。
临时规避方案:
- 推荐方案:将 VPN 认证方法从 PEAP 切换为 EAP-TLS(基于证书认证)。EAP-TLS 安全性更高,且不受此 Bug 影响,同时也是应对 CVE-2026-33824 的长期最佳实践。
- 临时方案:在 Intune 中创建功能更新暂缓策略(Feature Update Deferral),阻止关键 VPN 用户设备接收 26H1 更新,直至微软发布官方修复补丁。
另外,PEAP 认证失败往往会触发账户锁定策略。如果您在排查 VPN 问题时发现用户账户频繁被锁定,建议同步参考 Active Directory 账户频繁锁定排查完全指南,通过事件日志和 PowerShell 定位认证失败的源头。
PowerShell 诊断工具集
掌握正确的诊断工具可将故障排查时间大幅缩短。说真的,一套顺手的诊断脚本,能帮你把几小时的排查缩短到十几分钟。以下是 AOVPN 诊断的核心命令集合:
检查 VPN 连接状态与配置
# 查看所有系统级 VPN 连接(设备隧道)
Get-VpnConnection -AllUserConnection
# 查看当前用户 VPN 连接的详细配置
Get-VpnConnection -Name "企业用户隧道" | Format-List *
# 查看实时 VPN 连接状态
Get-VpnConnection -AllUserConnection | Select-Object Name, ConnectionStatus, TunnelType
DNS 排查 — 必须用 Resolve-DnsName 而非 nslookup
启用 NRPT(名称解析策略表)后,nslookup 会绕过 NRPT直接查询网卡配置的 DNS,结果无法反映 VPN 内部名称解析的真实情况。必须改用 PowerShell 的 Resolve-DnsName:
# 正确方式 — 遵守 NRPT 规则,反映 VPN 实际 DNS 解析
Resolve-DnsName -Name "internalapp.corp.example.com" -Type A
# 查看当前 NRPT 规则
Get-DnsClientNrptPolicy -Effective
# 查看 NRPT 规则详情
Get-DnsClientNrptPolicy
VPN 服务器连通性测试
# 测试 IKEv2 端口(UDP 500 和 4500)
Test-NetConnection -ComputerName vpn.corp.example.com -Port 500
Test-NetConnection -ComputerName vpn.corp.example.com -Port 4500
# 测试 SSTP 端口(TCP 443)
Test-NetConnection -ComputerName vpn.corp.example.com -Port 443
# 路由追踪诊断
Test-NetConnection -ComputerName vpn.corp.example.com -TraceRoute
查看 AOVPN 部署日志
# Intune 部署脚本写入的日志
Get-Content "C:\ProgramData\AOVPN\*.log" -Tail 50
# 查看 VPN 相关系统事件(最近 50 条错误)
Get-WinEvent -LogName "Application" -MaxEvents 200 |
Where-Object {$_.ProviderName -like "*RemoteAccess*" -and $_.LevelDisplayName -eq "Error"} |
Select-Object TimeCreated, Message |
Format-List
拆分隧道与零信任最佳实践
- 优先使用拆分隧道(Split Tunnel):在 ProfileXML 中设置
RoutingPolicyType为SplitTunnel,将 Microsoft 365 和 Teams 流量排除在 VPN 之外,大幅降低 RRAS 服务器负载并提升用户体验。微软官方也建议对 M365 Optimize 类端点不走 VPN 隧道。 - 配置 TrustedNetworkDetection:通过内部 DNS 后缀识别受信任网络,设备在公司内网时自动断开 AOVPN,避免双重路由和策略冲突。
- 证书自动续期:在 Intune SCEP 配置文件中将续期阈值设为 80%(证书有效期剩余 20% 时自动续期),防止因证书过期导致企业大规模 VPN 中断。
- 设备隧道仅限企业版:通过 Intune 推送 MAK 激活密钥可将 Windows Pro 升级为 Enterprise,解锁设备隧道功能。Autopilot 场景下尤其注意验证版本。
- IKEv2 安全加固:在 RRAS 服务器上通过以下命令强制使用更强的 IKEv2 密码套件,抵御加密降级攻击:
Set-VpnServerConfiguration -CustomPolicy `
-AuthenticationTransformConstants SHA256128 `
-CipherTransformConstants AES256 `
-DHGroup Group14 `
-EncryptionMethod AES256 `
-IntegrityCheckMethod SHA256 `
-PfsGroup PFS2048
Restart-Service RemoteAccess
常见问题解答
Always On VPN 设备隧道为什么只支持 Windows 企业版?
微软将设备隧道功能限定在 Windows 10/11 Enterprise 和 Education 版本,因为它需要在用户登录前以 SYSTEM 权限建立 VPN 连接,涉及域控访问、Autopilot 配置推送等纯企业场景。如果 Intune 托管设备运行 Windows Pro 版,可通过 Intune 推送 MAK 激活密钥将其升级为 Enterprise 版以启用设备隧道功能。
Always On VPN 和 DirectAccess 有什么主要区别?
DirectAccess 强依赖 IPv6 和 ISATAP/Teredo 过渡协议,仅支持域加入的 Windows 企业版设备,且服务器端配置复杂。Always On VPN 不依赖 IPv6,支持 IKEv2/SSTP/L2TP 多种协议,与 Intune 和 Entra ID 深度集成,同时支持混合加入和纯云加入场景。微软已于 2021 年停止 DirectAccess 的新功能开发,官方推荐迁移至 AOVPN。
如何确认 CVE-2026-33824 漏洞补丁已应用到 RRAS 服务器?
在 RRAS 服务器上以管理员身份运行 Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20,确认 2026 年 4 月的安全累积更新已安装。也可在 Windows Update 历史记录(设置 → Windows Update → 更新历史记录)中搜索对应的 KB 编号来验证。
为什么 AOVPN 在公司内网中仍然保持连接状态?
这是因为 ProfileXML 中未配置 TrustedNetworkDetection 参数。在 VPNProfile XML 中添加 <TrustedNetworkDetection>corp.example.com</TrustedNetworkDetection>,将内部 DNS 后缀设为受信任网络。客户端检测到该 DNS 后缀可达时,会自动断开 AOVPN 隧道,避免双重路由和策略冲突。
Intune VPN 配置文件分配成功但设备未出现 VPN 连接,如何排查?
首先手动触发 Intune 同步(设置 → 账户 → 访问工作或学校账户 → 信息 → 同步)。其次在 Intune 管理中心检查该设备的配置文件状态,确认受信任根证书和 SCEP 证书配置文件均已成功部署(VPN 配置文件依赖这两个前置配置文件)。最后查看设备事件日志中 DeviceManagement-Enterprise-Diagnostic-Provider/Admin 路径下的详细错误记录。


