为什么 Always On VPN 在办公网络中不再自动触发

笔记本接入办公 Wi-Fi 后，原本在家能连上的 Always On 配置文件却保持在断开状态。事件日志里不会把它记为失败，因为从客户端角度看，这个网络是受信任的，隧道没有必要建立。做出这个判断的是受信任网络检测功能，它比较的是具体数值，而不是识别熟悉的 SSID。当判断出错时，需要看清是哪一项比较通过了。

触发器到底比较什么

要让客户端把某个网络视为受信任，三件事必须同时成立。第一，Windows 为物理适配器记录的连接特定 DNS 后缀必须出现在配置文件的应后缀列表中。第二，Windows 为这个网络保存的连接配置文件必须是策略所期望的那一个，因为匹配针对的是该配置文件，而不是用户在无线对话框中输入的名字。第三，网络必须按策略要求完成分类，实践中这意味着域网络或专用网络，或者策略通过管理渠道下发的设备。三者缺一，触发器就会生效。

这比比较 VPN 的公网出口地址更窄，也比信任某个 SSID 窄得多。仅仅重复企业名称的接入点，本身并不能满足后缀与配置文件的比较。这也意味着该功能并不判断网络是否安全，它只判断这台设备是否认为自己已经在家。

修改配置文件前先读取当前状态

先从 Windows 当前的认识入手。连接配置文件 cmdlet 会报告网络名称、接口以及 Windows 分配的类别，也就是上面的第三项比较。然后读取 VPN 配置文件，找出受信任后缀列表，请使用完整的属性转储，而不是猜测属性名：

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

如果该转储在你使用的版本上没有暴露受信任后缀，就回到配置文件的 XML，当不同版本之间属性接口有差异时，XML 才是权威副本。从管理策略或所有用户的配置文件存储中读取该 XML，并把它的后缀条目与上面报告的适配器后缀对比。在改动任何一项之前，先把两个值都记录下来。

双向测试边界

在预期的企业接入点和另一个已批准的网络上分别测试，并记录隧道是否建立。然后离开网络后再测同一台设备。在家能触发、在办公室被抑制的笔记本属于按设计工作，而在任何地方都不触发的设备另有故障。在触发的情况下还要确认隧道后面的资源可以访问，因为隧道启动并不等于链路可用。

不要为了让通知消失就添加一个宽泛的后缀。一个在许多网络上都出现的后缀，会让客户端在几乎所有地方都抑制隧道，随之而来的支持负担比通知本身更糟。要通过配置文件的属主来修改条件，在受管环境中那是 MDM 管理员，而不是坐在笔记本前的人。

把两个测试网络连同结果一起记录下来。从未测试过的边界只是一句断言。

把抑制和阻断分开

没有启动的隧道不是被阻断的连接。受信任网络检测控制的是自动触发，而流量过滤与 kill-switch 行为是各自拥有失效模式的独立策略设置。受信任网络上的设备可以合法地把流量发到隧道之外，不读策略就把这称为泄漏，是把两种设计混为一谈。在把泄漏归咎于检测之前，先检查配置文件的流量规则。

同样的区分也解释了反向的抱怨。报告 VPN 无故停止的用户，通常描述的是满足了条件的网络变化，而不是服务故障。匹配到的后缀和网络类别才是应当收集的证据，两者都会出现在上面的输出中。

在修改策略之前先收集这些证据。隐藏症状的开关，也会隐藏原因。

记录判断依据

把匹配到的后缀、连接配置文件名称和网络类别写进每个站点的部署说明。当隧道无法建立时，这份记录就把谜团变成一次比较：要么三个值中有一个变了，要么策略变了。它也让下一位工程师能够确认设计，而不是为了关闭工单而停用检测。

站点改名或域合并时，要复查后缀列表，因为过时的条目会继续悄悄抑制隧道。Microsoft 关于受信任网络检测的参考文档列出了配置文件元素和部署前提，当有人提议扩大列表时，该引用的就是这份文档。