NPS 组策略不是 VPN 资源强制

两个组，两套访问配置，一个 VPN 网关，结果两个组都能到达同一批服务器。常见原因并不是策略出了问题，而是设计缺了后半段：NPS 决定谁可以建立会话，而会话能到达哪里必须由另一处决定。只做了前半段时，任何通过身份验证的人都会授权成功。策略在尽它的职责，设计却仍不完整。

按组匹配的网络策略是关于准入的证据。它并不是关于数据包的证据，而这项工作的大部分就发生在两句话之间的空隙里。

找出真正放行该会话的策略

NPS 按顺序评估网络策略，第一条条件匹配且已启用的规则胜出。条件可以包括用户或计算机组成员身份、连接类型、时间和设备状态。因此，排在列表前面的宽泛策略会先放行连接，后面更窄的规则根本轮不到被考虑。顺序不是界面的细节，它就是策略本身。

按顺序阅读列表，找出匹配的那一条，然后记下它返回了哪些设置。编辑器里的组名不是结果；真正的结果是服务器收到的授权。部署中同时使用用户授权和设备授权时，要把两者分开，因为一个能打开隧道的账号，并不自动就是应该访问所有内部服务的账号。

Filter-Id 属性携带的是一个过滤器列表的名称。它并不会附带一套每个接收方都理解的、可移植的数据包过滤规则；发送一个网关从未定义过的名称，则什么也强制不了。同样的告诫也适用于 VLAN 属性：把隧道会话分配到一个 VLAN，本身并不是该用户的路由访问规则。

在 NPS 一侧看起来完整的设计，恰恰是在这里悄悄什么都不做。请不要假定标准属性名就意味着标准行为，而应查阅网关厂商的文档，确认支持哪些授权属性，以及接收方对每一个属性如何处理。

处理用户数据包的网关可以施加按会话的过滤器、把某个组映射到网关策略，或者从防火墙区别对待的独立地址池中为会话分配地址。这些做法中的任何一种都可能有效，而它们失败的方式各不相同。在编写指名该机制的策略之前，先确认你的网关支持哪一种机制。然后把该机制缺失时会话会怎样写下来，因为默认情况就是沉默。

用四个部分描述预期权限：源身份或组、目标、协议和端口。把用户真正需要的依赖项加进去，例如 DNS 或身份验证服务，否则这条限制会破坏没人想到要测试的登录流程。规则要针对真正执行过滤的接口来写，而不是针对编辑器里恰好打开的那个接口。

还要把地址转换考虑进去。如果下游防火墙对每个隧道用户只看到一个转换后的源地址，它就无法仅凭这个地址区分个人；照着「可以区分」去写的规则，要么没用，要么过宽。

受管理的 VPN 配置文件可以推送路由、拆分隧道规则或应用过滤器，这些会塑造行为规矩的设备的表现。它们不是对服务的保护，因为客户端正是你要约束的一方。在配置文件里删掉一条路由也不等于授权，因为客户端可能还有另一条通往同一目标的路径。

把客户端设置当作便利，把网关设置当作控制。两者不一致时，网关是对的，因为看到数据包的是它。

创建两个权限意图不同的普通测试账号，建立全新会话，并检查各自实际生效的网关策略。然后测试一个无害的允许操作，以及一个被明确拒绝的资源。一次失败的 ping 本身说明不了什么，因为 ICMP 可能被过滤，而其背后的 TCP 服务照样应答。

当两个账号都仍获得宽泛访问时，按固定顺序追查：哪条策略匹配了、回复携带了什么授权、网关拿它做了什么。在确认接收方真的实现了这些属性之前就继续添加 NPS 属性，正是把一个小小的授权问题变成一次毫无结果的变更窗口的方式。