Сопоставление сайтов AD и привязка контроллера домена для клиентов VPN

Клиенты удалённого доступа в пуле 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, и политику, определяющую, что может делать вошедший пользователь. Сайт — не правило брандмауэра и не граница изоляции, и следующее изменение пула молча оторвёт удалённых пользователей от сетевой модели каталога, если сопоставление, маршруты и задокументированные альтернативы не движутся вместе.