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