Always On VPN 不是局域网访问权限：资源核查清单

Always On 描述的是连接的生命周期：配置文件在登录时或登录之前建立连接，并在用户不做任何操作的情况下自动重连。但这并不表示所有专用目标、协议和用户都被放行。真正要问的是这套已部署的配置文件究竟交付了哪些资源，而回答这个问题必须逐个资源核查，而不是看 Connected 标记。

第 1 步：先写下资源，再动手测试

为每个应用建立一条简短记录，数值必须来自真实环境：名称、目标前缀、服务与端口、隧道角色、身份组以及解析器路径。

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

这条记录会逼出四个彼此独立的问题。路由决定地址往哪里走；DNS 策略决定客户端如何得知该地址；流量过滤器决定这部分流量能否使用该连接；目标自身的防火墙与应用权限决定请求是否被接受。这四件事没有一件是“隧道已连接”自动带来的。

第 2 步：确定应由哪条隧道承载

Windows Always On VPN 同时提供设备隧道和用户隧道，两者是独立配置的配置文件，证书与作用域都分开。设备隧道通常只承载登录前必需的基础设施，例如管理与域服务；员工日常应用的广泛访问一般属于用户隧道。

流量过滤器是设备隧道的特性，这也正是 Microsoft 示例用它来处理管理流量的原因。把那个示例照搬进通用的资源访问配置文件，得到的隧道能连上，却承载了错误的流量集合。请用 Get-VpnConnection 确认当前生效的是哪条连接，并在这条连接下测试。

第 3 步：针对真实地址核对路由

先把名称解析一次，再检查该地址的路由：Find-NetRoute -RemoteIPAddress 10.20.5.10 会报告选中的接口、下一跳和源地址。如果接口是物理网卡，说明该前缀不在隧道的路由集合中，或者客户端以拆分隧道的方式把它排除在外。此时应当与配置文件定义比对，而不是在前面加一条本地路由。

本地 route add 可能让测试通过，却在下次策略刷新时消失，所以改动必须落在受管理的配置文件里。请同时检查用户配置文件与设备配置文件中的该前缀，并检查拆分隧道开关：全隧道不需要逐前缀路由，拆分隧道则需要为每个专用前缀各配一条。

第 4 步：单独测试专用名称解析

专用名称走的是另一条策略路径。配置文件可以下发 NRPT 规则和 DNS 后缀搜索列表，这些规则只在隧道连接期间生效。用 Get-DnsClientNrptPolicy 读出客户端实际收到的内容，然后在同一次会话里分别测试一个名称和一个地址。地址通而名称不通，问题出在解析器；两者都不通，问题出在路由。

名称也可能解析到隧道路由之外的一个地址，于是成功与超时混杂在一起。请把返回的地址与记录中的前缀对照；若不一致，说明专用区域返回了公网或备用地址，命中的那条路由并不是你设计的那条。

第 5 步：核查过滤器、身份与应用自身的关口

流量过滤器限定哪些协议和端口可以使用设备隧道，集合过窄就会挡住路由本可承载的资源。配置文件把连接指派给某个组，但资源本身还有自己的授权：能连上并不等于文件服务器会接受这个用户。

修改受管理的配置文件要通过它的归属方，无论是 Intune、ProfileXML 部署还是运维脚本；随后在正常重连之后和重启之后再测一遍，因为常见故障正是残留的本地路由或只生效过一次的配置文件。请把配置文件版本与测试结果一并留存。