NPS 的 RADIUS 客户端应登记哪个地址？

把身份验证交给 Windows NPS 的 VPN 网关，必须先有 NPS 侧的一个对象，任何用户策略才能运行：为网关创建一条 RADIUS 客户端条目。多数失败的尝试登记了错误的地址，因为真正重要的是网关在后端路径上使用的地址，而不是员工在 VPN 应用里输入的主机名。这个值一旦填错，NPS 会静默丢弃请求，从客户端看就像密码错误。有三项条件决定该填哪个地址，所以打开控制台之前先把它们理清。

登记网关，而不是笔记本或地址池

RADIUS 客户端对象代表发送身份验证请求的网络接入设备。那是 VPN 网关，不是每台运行客户端的笔记本，也不是隧道内分配的地址范围。

那些隧道地址永远不会作为 RADIUS 请求的源出现，因为请求走的是网关自己的网络路径。登记客户端地址池条目只会产生一条永远无法匹配的策略，而真正的请求来自 NPS 从未见过的地址。同样的混淆还让人把每位员工的家庭 IP 都加进去，既难以维护又错误。

三项条件决定你填写的地址

第一，找出网关实际发往 NPS 的源地址。多接口网关常常从管理接口或后端接口发送，而不是公网 VPN 监听接口。第二，检查两者之间是否有 NAT：如果请求被转换，NPS 看到的就是转换后的地址，那才是要登记的值。第三，如果两台网关分担这个角色，每个请求源都需要自己的客户端条目，因为一个只有单个地址的对象只能覆盖其中一台。

两端对照的记录能让这一对保持对齐。下表用私有地址作示例，请替换成你的路径实际使用的地址。

要确认源地址，而不是猜测。在一次尝试期间查看 NPS 或防火墙日志，或者在 NPS 主机上用 sudo tcpdump -ni any udp port 1812 抓包。抓包中出现的地址才是客户端条目唯一站得住脚的答案。如果网关有多个可能的源，就分别为每个源以其各自的友好名称登记。

共享密钥是网关与 NPS 之间的值

共享密钥用于验证设备之间的关系。它不是用户密码，也从不分发给员工或嵌入客户端配置文件。

选一个值，两处都填，并存放在网关配置备份所在的位置。不一致会产生一个被 NPS 丢弃、又不给出有用错误的请求，这在网关日志里与服务器不可达无法区分。在维护窗口内轮换，并在同一次变更中更新两端。

用一次被允许的请求确认

使用一个受控账户，在两侧关联同一次尝试。在网关侧确认请求确实发往目标服务器；在 NPS 侧确认请求来自已登记的客户端，并匹配预期的连接请求策略。超时与拒绝含义不同，把两者都当成凭据问题会浪费接下来的一小时。然后测试一个有效但不符合条件的账户和一个错误密码，因为什么都接受的策略同样能通过第一项测试。

最后，检查网关如何处理返回的授权。登记 RADIUS 客户端只是允许设备参与，它并不会让由此产生的每个会话都能访问局域网。

把诊断输出限制在范围内：支持工单里不要出现共享密钥、用户密码或完整的报文负载。如果设计要求 NPS 服务器读取目录属性，那项权限是与客户端登记分开的管理任务，缺失时会以另一种方式失败。