Робочий публічний DNS не означає, що Active Directory можна знайти

VPN підключається, браузер відкриває публічний сайт, а ноутбук досі не може увійти в домен. Звичний висновок — DNS у порядку, бо імена розв’язуються. Це не так, і причина в тому, що перевірка в браузері задіює лише один запит із ланцюжка, потрібного клієнту, приєднаному до домену. Виявлення домену спочатку запитує записи служб, потім адреси контролерів, які називають ці записи, і нарешті маршрут до портів, на яких ці контролери слухають. Публічна відповідь не задовольняє жодного з цих кроків.

Міф: імена розв’язуються, отже DNS готовий

Те, що публічний сайт розв’язується, каже лише про те, що якийсь розв’язувач відповів на один запит A або AAAA для імені в публічній зоні. Active Directory використовує той самий протокол для іншого питання: де служби домену і який контролер має використовувати цей клієнт. Питання виражається записами SRV у зоні, названій за доменом, а в рекурсивного публічного розв’язувача немає причин їх тримати.

Коли запису немає, розв’язувач повертає негативну відповідь, що є припустимою відповіддю DNS, а не збоєм. Далі клієнт повертається до кешованої інформації про контролери, якщо вона є, і саме тому настільний комп’ютер може годинами виглядати добре, а потім відмовити після перезавантаження або зміни пароля.

Що насправді запитує клієнт домену, по порядку

Для домену на кшталт corp.example загальний запит локатора — _ldap._tcp.dc._msdcs.corp.example. Відповіді SRV називають кандидатів у контролери та їхні порти, а потім клієнту потрібні записи адрес для цих імен вузлів, перш ніж відкрити з’єднання. Виявлення з урахуванням сайту додає запити в піддомені сайту, і відповіді визначають, які контролери бажаніші, а не який обов’язковий.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Просувайтеся ланцюжком у цьому порядку, з мережі, де виникає проблема. Ім’я вузла, що розв’язується в недосяжну адресу, — це збій маршрутизації, а не збій DNS. Досяжний контролер, у якого відсутні записи локатора, — це збій DNS, а не збій маршрутизації. Обидва дають схожі скарги користувачів і цілком різні способи виправлення.

Чому публічний розв’язувач відповідає, а вхід усе одно ламається

Якщо адаптер дає клієнту публічний розв’язувач, публічні імена працюють, а внутрішній простір імен — ні. Додавання другого публічного розв’язувача не допомагає, бо жоден із них не тримає зону. І звичний список «спочатку внутрішній, потім публічний» не поводиться як правило для кожного домену: негативна відповідь першого сервера — це законна відповідь, і клієнт не повторює запит до другого сервера лише тому, що відповідь була порожня.

Обидва внутрішні розв’язувачі, якщо ви тримаєте два, мають містити простір імен AD і бути досяжними з поточної мережі клієнта. Саме це ламають схеми розділеного тунелю: VPN може нести підмережу тунелю, а внутрішній розв’язувач перебуває в префіксі, який тунель не маршрутизує, тож запит виходить до розв’язувача, який не може на нього відповісти.

Windows також застосовує політику розв’язання імен, яка може спрямовувати певні простори імен до певних серверів, а адреси DNS, які показує адаптер, — це не вся історія. Зміна списку адаптера без зміни цієї політики може залишити чинну конфігурацію недоторканою, і тому виправлення, яке виглядає застосованим, не дає жодного ефекту.

Тримайте DNS тунелю та його маршрути узгодженими

Профіль VPN, який передає розв’язувач, але не префікс, що його містить, створює розв’язувач, недосяжний для клієнта; профіль, який передає префікс без розв’язувача, залишає клієнта питати локальний. Розглядайте пару як один елемент конфігурації та перевіряйте обидва після кожної зміни профілю, бо перевпорядкована передача або нова політика розділеного тунелю може їх розділити.

Перевірте також, що клієнт робить із переданим налаштуванням. Деякі клієнти застосовують сервер DNS лише до інтерфейсу тунелю й залишають розв’язувач фізичного адаптера на місці, тож переможець залежить від метрики інтерфейсу та запитуваного імені. Якщо внутрішня відповідь надходить лише коли фізичний адаптер вимкнено, виправляти треба саме цей механізм, а не записи домену.

Приймайте за викликом виявлення та однією живою операцією

Корисний приймальний тест запускає запит локатора, а потім виконує одну справжню автентифіковану операцію, наприклад відкриває спільний ресурс на основі каталогу або запитує квиток. Зробіть це до переходу на VPN і ще раз після нього, на тій самій машині, без перезавантаження між ними. Кешовані облікові дані та вже відкриті сеанси радо зроблять зламаний шлях здоровим, тож успішний вхід на робочий стіл — не тест.

Рекомендації Microsoft для клієнта DNS проводять ту саму межу між розв’язанням внутрішнього простору імен і передаванням публічних запитів угору, і це та схема, яку треба зберегти під час упровадження VPN.

Якщо збій лише повільний, а не остаточний, тримайте затримку окремо від діагностики. Тайм-аут під час виявлення може походити від недосяжного контролера, заблокованого порту або розв’язувача, що відповідає пізно, і жодне з цього не доводиться самим очікуванням. Зафіксуйте фактичний запит, його відповідь і спробу з’єднання, перш ніж змінювати налаштування розв’язувача.