为什么 RADIUS 的 VLAN 应答对 VPN 用户毫无作用

你在 NPS 策略里加上 VLAN 属性，VPN 用户连上来，笔记本却仍然落在默认地址池。RADIUS 服务器返回的正是你要求的内容，于是故障看起来像缓存问题。通常并不是。Access-Accept 携带的是授权提示，只有收到提示的网络访问服务器才能把其中一条变成网络分配。

从网关开始，而不是从策略开始

在改动任何东西之前，先从客户端向内走一遍链路。客户端向网关请求会话，网关向 RADIUS 询问该用户能否获得会话，RADIUS 用一个结果和一组属性作答。随后网关应用它知道如何应用的内容。

你的排查从第四步开始，所以前三步看着都正常。交换过程里没有任何东西强制网关去实现它收到的属性。应答是对网关的请求，不是关于客户端的事实。

交换机做得到而 VPN 做不到的事

802.1X 接入交换机是带端口的认证器，动态 VLAN 分配把其中一个端口移入交换机已经承载的 VLAN。RADIUS 隧道属性以交换机理解的形式描述这一意图。路由型 VPN 终结的是隧道，不是交换机端口，其客户端通常拿到地址和路由，而不是成为广播域的成员。没有端口可移，所以同一个属性没有作用对象。

这是模型差异，不是厂商缺陷。有些网关会加上在截图里看起来相似的自己的组策略、地址池选择或过滤机制。另一些什么都不实现，属性只被记录然后忽略。请阅读你实际启用的远程访问模式的文档，而不是截图里的那个。

读懂服务器实际发出的应答

确认 RADIUS 返回了什么，而不是策略编辑器显示了什么。用同一用户名和已知密码发一个测试请求，会把应答属性以可读形式打印出来，一步就能定论。

radtest alice secret 10.0.0.10 0 testing123

如果该应答里没有 VLAN 属性，先修正策略匹配。如果有，说明服务器已完成自己那部分，缺口在下游。

先证明会话策略，再证明可达性

现在看网关建立的会话。活动会话列表显示地址池、已分配的地址以及网关附加的任何组策略，这才是对执行唯一有意义的证据。把它与用户实际能访问的内容比较，而不是与策略的意图比较。

swanctl --list-sas

然后从客户端测试一个被允许和一个被拒绝的资源，因为来自正确地址池的地址并不能证明隔离。如果网关没有实现你想要的那种分配机制，再多的属性副本也不会凭空造出一个。来自预期地址池的地址可能与对其余每个池的完全访问并存。选择受支持的策略机制，或者有意改变网络设计。