Раздельный туннель исключает браузер, а не его DNS-запросы

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

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

Путь данных и путь резолвера разделяются

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

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

Найдите, какой процесс задаёт вопрос

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

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Прочитайте действующую конфигурацию перед тестированием: какие соединения несут DNS-серверы, какие пространства имён они заявляют и переопределяет ли политика для отдельного имени значение по умолчанию. В Linux раздельный DNS использует домены маршрутизации; в Windows таблица политики разрешения имён делает то же для пространств имён. Ни то, ни другое не видно со страницы теста утечки.

Решите, какой резолвер видит какое имя

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

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

Не переписывайте каждое поле DNS, чтобы одна метка теста стала зелёной. Метка описывает один запрос одного процесса в один момент.

Проверяйте запрос и соединение отдельно

Проверьте оба пути независимо. Тест соединения показывает маршрут данных, а тест резолвера показывает, кто получил имя.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

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

Похожие статьи