VPN 客户端的 AD 站点映射与固定域控制器之比较

VPN 地址池中的远程访问客户端，可能会跑去和地球另一端的域控制器通信。修正它有两条路：把地址池描述为与正确控制器所在站点绑定的 Active Directory 子网，或者把客户端或应用固定到某一台控制器。前者是 DC Locator 可以据以行动的拓扑声明。后者是按应用逐项覆盖，完全无视拓扑。两者的代价不同，而今天图快先抓一条，正是目录团队最后不得不两头都维护的原因。

两种做法究竟改变了什么

子网对象是目录中的一条记录，说明某段地址属于哪个站点。在装有 Active Directory 模块且站点已存在的情况下，这项操作小到可以先预览：

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf 会预览对目录的写入。它既不会创建对象，也不会测试该网段内的客户端能否访问任何东西，而这恰恰是人们期待它做的事。DC Locator 在解析服务记录时读取站点模型，所以一个准确的子网对象会改变提供给客户端的结果。

固定则在另一个层面起作用。应用配置里写死的控制器名称、内含主机名的 LDAP 字符串，或指定首选服务器的注册表值，都会把发现过程从路径上拿掉。应用会一直和那台控制器通信，直到有人改动设置；故障切换则取决于该应用自己实现了什么。

子网映射在何处取胜

映射地址池只需描述一次网络位置，对所有使用 DC Locator 的客户端都成立。当地址池从一个 /24 扩到三个时，模型只改两三个对象，而不是改一份应用清单。这就是全部优势，而当客户端规模不在你手里时，这个优势很大。

麻烦在于对象必须与控制器实际看到的地址一致。如果 VPN 网关把每个客户端都转换成枢纽地址，那么添加未转换的地址池，描述的是一个任何控制器都观察不到的网络位置。要尽早决定设计是否保留客户端源地址；如果不保留，就应映射转换后的网段，而不是你在 VPN 服务器上配置的那个池。

第二个限制：站点模型是一种偏好，也是一条拓扑声明。它不让控制器变得可达，也不给用户任何权限。可达性由路由和防火墙策略负责；授权由账户策略负责。

固定又在何处取胜

当发现机制根本无法工作时，固定才是正确答案：依赖一个你改不了的名字来解析控制器的老旧应用、只放行某一个控制器地址的过滤器，或者控制器本就是应用设计一部分的固定服务器集合。在这些情形下，固定是在记录真实约束，而不是抄近路。

它的代价与映射相反。固定的名字不会跟着地址池走，除非应用自己会做，否则不会故障切换，也经不起控制器改名或下线而无人盘点。它还会掩盖拓扑问题，因为每个固定的客户端看上去都很健康，而站点模型却在悄悄烂掉。

用一台首选服务器替换域内普通地址记录，并不是第三种选择。它会破坏所有期待正常发现集的消费者，而且仍然控制不了了解目录的客户端如何选择站点。

按三个条件来选

按这个顺序自问，决定通常会自己浮现。第一，应用到底用不用 DC Locator，还是本来就带着控制器地址？第二，控制器看到的是池地址，还是转换后的地址？第三，相比固定需要更新的位置数量，地址池变化的频率有多高？

了解目录的应用，加上保留源地址的路由，再加上会变化的地址池：映射子网。无法发现的应用，或只允许一个地址的过滤器：固定它，并把原因写下来。其余情况都该去修拓扑，而不是再加一层覆盖。

从 VPN 客户端验证，并把三份契约分开保存

要从真实的远程路径测试，而不是从已经坐在站点里的 LAN 工作站测试。只有客户端自己的视角才算数：

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

如果报告的站点正是你映射的那个，说明对象对上了。如果客户端报告不出站点，说明它呈现的地址不在任何子网对象内，通常意味着发生了地址转换，或者前缀已经过时。接着在断定映射失败之前，先确认选中的控制器就是你预期的那个，因为客户端会缓存发现结果，故障切换合法地选中另一台也很正常。

把三份契约放在同一份文档里：地址池及其子网对象、从 VPN 路径可达的控制器，以及决定已登录用户能做什么的策略。站点不是防火墙规则，也不是隔离边界；如果映射、路由和成文的替代方案不一起变动，下一次地址池变更就会悄悄地把远程用户从目录的网络模型里摘出去。