Резервный DNS вашего VPN: куда на самом деле уходит запрос

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

Резервный путь — это политика, а не единственное поведение

Каждый клиент должен решить, что делать, когда предпочитаемый резолвер перестаёт отвечать. Он может заблокировать разрешение, повторить попытку, использовать настроенную альтернативу или положиться на операционную систему, и с точки зрения приватности это четыре разных продукта. Чтение экрана настроек говорит, какое поведение настроено; оно не говорит, какое произошло. Экран с одним переключателем не описывает четыре возможности.

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

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

Кто получает запрос после переключения

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

Внутренние имена делают различие конкретным. Публичный резолвер обычно не может ответить на имя из split-horizon, поэтому запрос завершается неудачей, хотя имя уже раскрыто стороне, которой нечего было его видеть. Доступность и приватность здесь идут вместе, а не обмениваются друг на друга.

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

Проверяйте маршрут и получателя вместе

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

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

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

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

Решите, должен ли резервный путь быть разрешён

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

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

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