Действительно ли используется DNS вашего VPN? Перехватите порт 53 и посмотрите

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

Протолкнутая опция — не запрос

Первый этап — сервер предлагает настройки, например протолкнутую опцию DNS, называющую распознаватель внутри туннеля. Второй этап — клиент применяет эти настройки к интерфейсу. Третий этап — приложение действительно отправляет запрос на этот адрес. Отказ на втором этапе оставляет опцию видимой в журнале соединения, а список распознавателей остаётся неизменным, а отказ на третьем этапе оставляет совершенно правильный список распознавателей неиспользованным.

Большая часть диагностики сливает эти три в один и винит сервер VPN, который обычно единственная сторона, способная доказать, что выполнила свою часть. Читайте вместо этого реальное состояние распознавателя клиента, затем проследите выход одного запроса. Эти два наблюдения отделяют конфигурацию от маршрутизации и от политики, и они стоят около пяти минут. Сохраняйте записи, потому что следующему инженеру нужны «до» и «после», а не их описание.

Проверьте, что действительно держит интерфейс

В Linux системным распознавателем может быть обычный файл, NetworkManager или systemd-resolved, и то, кто из них им владеет, определяет, где осядет протолкнутый сервер. Процесс OpenVPN из командной строки сам не обновляет системный распознаватель, поэтому документированная интеграция — это скрипт up/down или менеджер соединений, который уже умеет применять настройки. Запускать оба — эффективный способ создать гонку.

resolvectl status
cat /etc/resolv.conf

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

Проследите один запрос за пределы машины

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

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

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

Брандмауэр, который принимает только собственный DNS

Коммерческие клиенты иногда устанавливают собственные цепочки фильтрации. Один документированный шаблон разрешает DNS к собственному распознавателю клиента и отбрасывает весь оставшийся трафик UDP на порту 53, который пытается покинуть интерфейс, не являющийся loopback, включая трафик, который пользователь намеренно направил в другое место. Запросы демона исчезают без следа, что читается как отказ распознавателя, а не как фильтр.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

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

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

Почему страница утечки доказывает меньше, чем кажется

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

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