VPN подключён, но имена не разрешаются: где на самом деле ломается DNS

Туннель поднят, значок зелёный, и каждая вкладка браузера сообщает об ошибке разрешения имён. Эту картину создают три разных механизма: резолвер может быть недоступен, клиент может спрашивать резолвер, которого вы не ожидали, или отказывать могут только частные имена. Разделите их, прежде чем менять что-либо в протоколе туннеля, потому что каждый чинится в другом месте. Порядок ниже начинается с наблюдений, которые отделяют эти три случая.

Что на самом деле нужно запросу

Запросу нужны три вещи: адрес резолвера, маршрут до этого адреса и ответ, соответствующий вопросу. Каждое может отказать само по себе, а видимый симптом — та же страница, которая не загружается. Поэтому страница ошибки почти ничего не говорит, пока вы не знаете, что именно из трёх сломалось.

Клиент узнаёт свой резолвер из профиля VPN, из DHCP на туннеле или из собственной конфигурации, и то, какой источник победит, зависит от платформы. В Windows ipconfig /all выводит DNS-серверы по каждому адаптеру, так что видно, дошло ли отправленное значение на самом деле. Отправленное значение, которое так и не дошло до операционной системы, — тихий и частый отказ. Прочитайте настроенное значение, прежде чем трогать профиль.

Linux и macOS отвечают на тот же вопрос другими командами, и ответ заслуживает такого же чтения: resolvectl status и scutil --dns оба перечисляют серверы по интерфейсам. Сравните этот список с адресом, который профиль якобы отправляет. Несовпадение здесь объясняет всё дальше, поэтому разберитесь с ним до проверки имён.

Проверьте одно публичное и одно частное имя

Запросите обычное публичное имя хоста и задокументированное частное имя хоста с одной и той же машины и запишите, какой сервер ответил на каждое. Если отказывают оба, сломан резолвер или его маршрут. Если отказывает только частное имя, резолвер ответил, и вопрос переходит к зоне или маршрутизации. Выполните оба запроса в пределах минуты друг от друга, чтобы смена маршрута не могла объяснить разницу.

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

nslookup печатает и сервер, к которому обратились, и полученный ответ, а это ровно та пара, которая нужна. Запустите её дважды в одной оболочке и запишите ответивший адрес рядом с каждым ответом.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Убедитесь, что клиент действительно достигает этого сервера

Частный резолвер, отправленный профилем, полезен только если клиент может до него добраться при поднятом туннеле. Адрес, который выглядит правильным, но без маршрута даёт тайм-аут, а подключённое состояние туннеля ничего не говорит об этом маршруте. Проверка — это поиск маршрута именно к самому резолверу, а не к конечной точке VPN.

Каждая платформа отвечает на это одной строкой, и интерфейс, названный в выводе, — это весь ответ. Если он указывает на физический адаптер, пока резолвер находится за туннелем, профиль не отправляет префикс, который его покрывает.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

В профиле раздельного туннеля резолвер может находиться вне отправленных маршрутов, и это проблема профиля, а не сервера. Сравните адрес резолвера с отправленными префиксами и убедитесь, что один из них его покрывает. То же несовпадение объясняет, почему DNS работает в одной сети и отказывает в другой с идентичным профилем.

Помните, что браузеры могут обходить системный резолвер

Браузер с включённым защищённым DNS может отправлять запросы по HTTPS выбранному им провайдеру и полностью игнорировать резолвер операционной системы. Тогда система выглядит правильно, пока браузер отказывает, или наоборот. Это вопрос политики браузера, а не туннеля.

Проверьте настройку защищённого DNS браузера и любую управляемую политику, которая ей управляет, затем попробуйте второе приложение или браузер при неизменном туннеле. Если отказывает только одно приложение, исправление относится к этому приложению. Приватное окно — не чистое сравнение, потому что в одном браузере оно может по умолчанию отключать расширения, а в другом нет, и оно никогда не обходит управляемую политику. Используйте вместо этого второй профиль браузера или другое приложение.

Очистите кеш и повторите проверку реальной задачи

После исправления настройки очистите локальный кеш резолвера, чтобы старый ответ не пережил исправление. Краткое восстановление, за которым следует новый отказ, означает, что причина всё ещё есть, а не что очистка не удалась. Выберите строку, соответствующую машине, на которой вы находитесь, потому что три кеша разные.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Затем повторите исходную задачу, а не синтетический запрос, потому что важна именно задача. Подключитесь заново один раз, чтобы повторная проверка охватила состояние, в котором пользователь действительно окажется. Справочник nslookup от Microsoft — это страница, которую стоит сохранить для аргументов запроса.

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