Работающий публичный 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.

Если сбой только медленный, а не полный, держите задержку отдельно от диагностики. Тайм-аут во время обнаружения может происходить из-за недоступного контроллера, заблокированного порта или резолвера, отвечающего поздно, и ни одно из этого не доказывается одним ожиданием. Зафиксируйте фактический запрос, его ответ и попытку соединения, прежде чем менять настройку резолвера.