Изменил ли VPN мой DNS? Сравните до и после
Профиль может намеренно перенаправлять ваши запросы. Сравните политику резолвера и фактический ответ до и после подключения VPN, сохраняя одну переменную.
Вы подключаете туннель, открываете приватную панель, и имя разрешается в адрес, которого вы никогда не видели. Или происходит обратное: браузер продолжает работать, а инструмент командной строки внезапно ничего не разрешает. Оба результата происходят от одного и того же изменения, и люди обычно объясняют это одной фразой о VPN, который «использует свой DNS», а этого недостаточно точно для диагностики или проверки. В этой фразе спрятаны два вопроса: какие запросы должен взять на себя этот профиль и отправила ли ваша машина их действительно тому резолверу, который ей выдали? Разделять их — это и есть весь метод, потому что тест, смешивающий их, даёт уверенный неверный ответ в обе стороны.
Почему профиль вообще предоставляет резолвер
Внутри туннеля имена за дальним концом обычно разрешаются в адреса, которые существуют только в этой сети. У частной зоны вроде corp.internal нет публичного делегирования, поэтому резолвер, который её обслуживает, должен быть доступен изнутри туннеля. Тот же механизм служит второй цели: когда запросы иначе уходили бы через вашего провайдера, резолвер на дальней стороне удерживает запрос внутри шифрованного пути. Поэтому адрес DNS-сервера приходит как часть политики соединения, а не как глобальная настройка, выбранная однажды для машины.
Сам адрес ничего не решает. Резолвер может ответить только если к нему есть маршрут, и самая частая неисправность — резолвер, доступный только пока поднят туннель. Когда туннель падает, а политика остаётся, запросы уходят на адрес без пути, и симптомом становится тайм-аут, а не чистая ошибка. Эта разница важна, когда вы читаете следующий результат теста, потому что тайм-аут отправляет людей в настройки транспорта, которые никогда не участвовали.
Сравните две схемы до сравнения ответов
Полный туннель и разделённый DNS дают противоположные ожидания, и ни одна из схем не является неисправностью. При полном туннеле каждый запрос может уйти к провайдеру или к корпоративному резолверу, поэтому разный ответ публичных имён после подключения ожидаем. При разделённом DNS только перечисленные домены идут к частному резолверу, а всё остальное остаётся локальным; в Windows список доменов живёт в Name Resolution Policy Table, в macOS — в соответствующих доменах настроек DNS, а на хосте с systemd-resolved — в доменах маршрутизации для каждого подключения.
Именно это сравнение нужно сделать первым, потому что оно решает, что считать дефектом. При разделённом DNS публичное имя, отвечающее от нового резолвера, — это то, что стоит исследовать, тогда как внутреннее имя, отвечающее правильно, — это система, выполняющая свою работу. При полном туннеле аномалией является публичное имя, которое всё ещё отвечает от резолвера вашего провайдера. Документация Microsoft о разрешении имён VPN описывает порядок Windows для этих правил, включая то, как подходящая запись политики учитывается раньше собственных серверов адаптера.
В комнате есть и третий резолвер, о котором легко забыть. Безопасный DNS браузера сам разрешает имена и может продолжать отвечать после того, как туннель изменил политику операционной системы, поэтому загружающаяся страница доказывает, что резолвер браузера работал, а не что профиль был применён. Если вы сравниваете только то, что показывает браузер, половину времени вы проверяете не тот уровень.
Запишите базовую линию только с одной переменной
Измените туннель. Не меняйте в том же шаге также имя, инструмент или суффикс поиска. Выберите имя, которое вам разрешено запрашивать, отметьте, какое приложение использовали, и запишите либо вернувшийся адрес, либо точную ошибку. В Windows Get-DnsClientServerAddress -AddressFamily IPv4 печатает серверы по адаптеру, а Get-DnsClientNrptPolicy — записи политики; в Linux с systemd-resolved resolvectl status показывает DNS-серверы и домены маршрутизации по подключению; в macOS scutil --dns печатает порядок резолверов, которому система действительно будет следовать.
Затем подключитесь через обычные элементы управления клиента и повторите в точности те же команды. Сохраните первый вывод, а не воспоминание о нём, потому что сравнение и есть весь смысл, а второе чтение после очистки кэша — это уже другое измерение. Если базовая линия снималась с браузером на переднем плане, а запуск после подключения происходит в терминале, вы сравниваете два резолвера, а не два состояния одного резолвера.
Явный запрос и поиск приложения — разные тесты
Запрос к одному конкретному серверу, через nslookup name 10.20.0.1 или dig @10.20.0.1 name, доказывает одну вещь: что названный вами сервер отвечает, когда до него можно добраться. Он полностью обходит логику выбора, поэтому не может сказать, выбрала ли бы система этот сервер для этого имени. Используйте его, чтобы проверить доступность назначенного резолвера, и не используйте для проверки политики.
Поиск через локальный резолвер действительно задействует выбор. resolvectl query name проходит те же правила доменов маршрутизации и сообщает, какой протокол ответил, Resolve-DnsName в Windows проходит через таблицу политик и кэш клиента, а scutil --dns показывает порядок, которому следовал бы поиск. Запустите оба типа и держите их в отдельных столбцах заметок. Успешный явный запрос рядом с неудачным поиском приложения — это проблема маршрутизации или выбора, а не резолвер, отказывающийся работать.
Кэш стоит между вами и ответом. Операционная система, локальный stub-резолвер, браузер и отрицательный кэш хранят результаты, поэтому поиск может удаться без единого пакета, покинувшего машину. Запишите результат, прежде чем что-либо очищать: ipconfig /flushdns, resolvectl flush-caches или sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder в macOS. Пропустите широкий сброс сети на этом этапе, потому что он уничтожает доказательства, которые вы ещё собираете.
Что означает разница
Сравните две записанные строки и классифицируйте изменение, прежде чем трогать хотя бы одну настройку.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Одна строка заслуживает акцента. Имя, которое разрешается, — это не работающий сервис, а успех DNS говорит лишь о том, что адрес найден. Он ничего не говорит о пересылке, правилах брандмауэра или о том, может ли ваша учётная запись вообще пользоваться сервисом, поэтому закончите проверкой реального приложения, а не предположением, что неисправность ушла сама.
Восстановите базовую линию и проверьте её
Отключитесь через собственные элементы управления клиента, а не убивая процесс, и затем снова прочитайте те же три команды. Серверы по подключению, записи политики и ответ для вашего тестового имени должны вернуться к базовой линии, которую вы записали ранее. Оставшаяся запись политики после чистого отключения — это реальный дефект, который стоит зафиксировать, и именно поэтому ручные правки сгенерированного файла резолвера — плохая привычка: файл перезаписывается и правка исчезает, либо правка выживает и закрепляет резолвер, у которого больше нет маршрута.
Пройдите этот список один раз, по порядку. Решите, какую схему реализует профиль, прежде чем оценивать любой результат. Держите имя, инструмент и суффикс фиксированными в обоих запусках. Отделите явный запрос от поиска приложения. Читайте действующую политику, а не только ответ. Очищайте кэши последними, после того как сравнение записано. Проверьте реальным приложением, затем один раз перезагрузитесь и подтвердите, что отключённое состояние по-прежнему чистое.