Почему nslookup разрешает через VPN, а браузер нет

nslookup отправляет запрос указанному серверу и печатает ответ, поэтому он может работать, когда каждая вкладка браузера терпит неудачу. Браузер просит операционную систему разрешить имя, а система взвешивает резолверы каждого интерфейса, правила политики разрешения имён и сетевое расположение адаптера. Затем браузер может добавить поверх собственный зашифрованный DNS. Три разных пути, один симптом, и туннель обычно не является сломанной частью.

Проверки ниже идут по этим путям от системы наружу. Не меняйте профиль VPN, пока не узнаете, какой путь ответил, а какой отказал.

Ответ определяют три политики

У каждого интерфейса свой список резолверов и суффиксы поиска. VPN-адаптер добавляет серверы, а физический адаптер сохраняет свои, и система может взять тот, который ответит первым, поэтому поиск может обслуживаться вне туннеля без чьего-либо выбора. Правила таблицы политики разрешения имён могут направлять выбранные домены на выбранные серверы, так обычно выражается split DNS в Windows. А клиент или шлюз VPN могут протолкнуть адрес резолвера, который существует только внутри частной сети.

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

Почему браузер задаёт другой вопрос

nslookup отправляет свой запрос выбранному им серверу и не следует ни политике пространства имён, ни настройке зашифрованного DNS браузера. Поэтому ручной запрос к публичному резолверу отвечает, тогда как браузер сообщает, что сайта не существует. Вы сравниваете две программы, а не два состояния одной программы.

Предпочтение семейства адресов объясняет задержку, а не отказ. Браузер, который в туннеле, несущем только IPv4, первым запрашивает записи IPv6, ждёт истечения тайм-аута, прежде чем отступить. Firefox держал такое предпочтение именно для этого, и его отключение — диагностический шаг, а не ремонт.

Прочитайте список резолверов и правила

В Windows выведите то, что хранит система, прежде чем строить теории. Get-DnsClientServerAddress показывает серверы по интерфейсам, Get-DnsClientNrptRule перечисляет правила пространства имён, а Resolve-DnsName отвечает на точное имя системным путём. Сравните этот ответ с прямым запросом к серверу VPN по адресу. Когда Resolve-DnsName падает, а прямой запрос проходит, подозреваемый — список резолверов или правило пространства имён.

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

Недоступный протолкнутый резолвер

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

Если резолвер недоступен, ремонт — это маршрут или включённая подсеть, а не другой DNS-сервер.

Зашифрованный DNS обходит весь путь

Браузеры с DNS-over-HTTPS сами разрешают имена через HTTPS-соединение с выбранным провайдером. Когда это включено, системный резолвер и правила split DNS полностью обходятся для таких запросов, поэтому внутренние имена падают в браузере, тогда как операционная система разрешает их правильно. Бывает и обратное: внутренние имена проходят в браузере через провайдера, который никогда не должен был их видеть, и это проблема политики, а не связности.

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

Ремонт, соответствующий сбою

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

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

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