VPN 认证域：哪个账户命名空间胜出？

每一次 VPN 登录都会落入某个账户命名空间，而域（realm）就是决定落入哪一个的选择器。它并不说明国家、服务器位置或信任级别。两个完全相同的用户名可以存在于不同的域中，因此正确的密码有时会认证到错误的账户。本操作手册先确认身份形式，再追踪请求直到真正做出应答的系统。

域选择的是什么

网关收到用户名后，必须决定去哪里核对。域就是这个用户名的一部分，或者紧邻它的属性，用来选择数据库：目录、RADIUS 池或本地账户文件。Microsoft 的 NPS 称其为域名，并据此路由连接请求；而 EAP 网络访问标识符在 RFC 7542 中把同一思想表示为 at 符号之后的后缀。两者都是选择器，谁也不判定凭据是否有效。

这种分离会产生两类截然不同的失败。路由正确但密码错误，只得到一次拒绝；而路由到错误数据库的域，可能拒绝正确密码，也可能接受别人的密码。两种错误都不会提到域，因此第一项诊断永远相同：查明究竟是哪一个系统作出了应答。

域的语法属于部署细节。有些服务要求不带限定的名称加一个属性，有些要求 user@domain，还有少数期望带反斜杠的形式，而多数指南从不提及。

使用后端所期望的形式

在照教程尝试后缀之前，先问运维人员应当输入哪种形式。带域限定的名称进入只接受简单名称的后端时，通常是在查找阶段失败，而不是密码校验阶段。同一个短名称出现在两个目录中，正是缺少域时危害最大的情形。

不要把管理账户当作证据。你管理服务的 Web 控制台可能对本地文件做认证，而隧道检查的却是完全不同的目录。请用真实用户会用的凭据，在真实用户会用的界面上测试。控制台登录成功，并不能说明网关对 VPN 认证采用了哪个域。

浏览器和邮件客户端有时会缓存先前的身份并静默重发。当报告的用户名与输入的不一致时，那个缓存就是第一个要查的地方。

通过代理追踪请求

在 FreeRADIUS 前端上，域在代理配置中声明，声明的后缀决定请求发往哪台归属服务器。动手之前先读那个文件，因为不匹配任何域的请求默认由本地处理。

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

grep 显示存在哪些后缀，以及每个后缀指向哪个池。radtest 调用会发送带域的名称和一个故意写错的密码，因此被拒绝就证明路由和凭据校验都执行了。这次尝试前后的日志行会显示名称在代理前是否被剥离，以及由哪台归属服务器接手。如果日志里根本没有域匹配，请求就没有离开本地服务器，问题在后缀而不在密码。

一次只改一处并重复尝试，因为只有各次运行的输入不同时，日志才能把路由问题与凭据失败区分开。在工具支持从文件或提示读取时，把共享密钥留在 shell 历史之外。

记录尝试而不泄露它

用管理员可以据此行动的形式记录故障：接口、身份形式、是否带域，以及准确但不涉密的错误。公开报告中去掉真实用户名，但保留域。把所有身份都涂成同一个占位符，恰恰会掩盖你要找的那种不匹配。时间戳也很重要，因为网关、代理和目录各自保存日志。

然后为用户记录胜出的形式，因为下一个输错的人会打开同一张工单。重置密码并不能修复总是落入错误命名空间的请求。域是路由决策，而路由决策要靠正确命名来修复。