FortiGate VPN 落入错误组：RADIUS 匹配

登录成功，隧道建立，用户却落在错误的策略上，或者根本没有落到任何策略上。FortiGate 日志里不会提示组缺失，因为从它这一侧看认证是成功的，只是组匹配没有触发。需要排查的这条链上有三个不同的名字，而它们通常并不是同一个字符串。

三个名字，三种职责

在动任何配置之前，先把这三个都写下来，因为其中两个位于不同的系统上。

目录组是 RADIUS 策略实际评估的对象。返回的属性是 Access-Accept 响应里的一个值。FortiGate 本地组则是策略按名字引用的容器。把其中任意两个混淆，就会得到能登录成功、却无法授权的局面。

匹配究竟发生在哪里

Fortinet 的 RADIUS 组匹配说明 指出，Fortinet-Group-Name 是默认的组属性。FortiGate 会把配置的远程服务器和组名取值，与响应实际携带的内容作比较，也就是说比较对象是返回的字符串，而不是你本地组的显示标签。

这就是为什么名为 VPN-Engineering 的本地组，可以和一个 vpn-engineering 的返回值并排存在却完全不匹配。在这项比较里，大小写和拼写不是装饰。选定一个字符串，在响应里使用它，并在网关的匹配规则里引用同一个字符串。

在 FortiAuthenticator 上，组必须与属性关联，并纳入相应的 RADIUS 服务策略，在适用的地方还要启用组属性返回控制。

响应可以成功，但不带属性

对 NPS 或其他 RADIUS 服务器，先在策略里强制目录组条件，然后再配置受支持的响应属性。密码校验成功本身就会产生一个 Access-Accept，而 不带组字符串的 Access-Accept 是完全有效的响应，它在 FortiGate 这一侧不授权任何东西。这是这个问题最常见的形态。

定义一个组，不等于把它发送出去。这是两个不同界面上的两个配置步骤，而通常只做了其中一个。

为什么把匹配放宽到 Any 是陷阱

当 RADIUS 服务器本来就只放行你想要的人群时，Any 远程组匹配是合理的设计。要有意识地选择这种委托。为了让缺失的属性消失而放宽匹配，会把 RADIUS 服务器碰巧接受的所有账号一并放进来，包括那些从来不该拥有 VPN 访问权的账号。症状消失了，访问控制却悄悄不复存在。

如果你说不出 RADIUS 服务器应该放行谁，那就还没准备好使用 Any 匹配。

为支持保留四条记录

当它仍然不工作时，收集四样东西：被选中的 RADIUS 策略、实际返回的组属性、用于比对的 FortiGate 服务器与取值，以及最终形成的本地组。这四条记录能在不暴露密码、也不为了看效果而改动组成员关系的前提下，定位断点。

在真实规则下测试一个被授权的账号和一个范围外的账号，并检查最终的策略与资源访问，以及认证结果。只有这一对结果，才能说明匹配是否真的按你想的那样工作。