Утечка DNS при VPN: оценка риска по пяти проверкам
Стандартный DNS-тест отправляет 6 запросов за один раунд. Расширенный выполняет 36 запросов за 6 раундов и может занять на 10–30 секунд больше.
Разница влияет на охват наблюдений, но не превращает результат в сертификат приватности: веб-тест показывает, какие резолверы обработали конкретные запросы в конкретном сеансе.
Проверка риска утечки DNS при VPN требует сопоставить результат с ожидаемым маршрутом, затем проверить настройки DNS и поведение клиента при сбое туннеля. Отдельно оцениваются IP, WebRTC и split tunneling. Универсальной шкалы из пяти проверок нет. Ниже это пять практических этапов аудита, а не единый стандартизированный балл.
1. Сравнить Standard и Extended
DNS Leak Test может отправлять уникальные имена для разрешения, а затем показывать резолверы, выполнившие запросы. Standard состоит из одного раунда и шести запросов. Extended использует шесть раундов и 36 запросов. Повторение помогает увидеть, меняется ли состав наблюдаемых серверов во времени, но расширенный тест не устанавливает полную цепочку перенаправлений DNS и не охватывает все приложения и сети.
Проверку проводят при подключённом VPN. Запишите состояние клиента, тип сети и показанные в тесте сведения о резолверах. Затем повторите тест в тех же условиях. Если результаты отличаются, это повод разбираться в маршруте и конфигурации, а не сразу объявлять утечку: на обработку могут влиять настройки клиента и инфраструктура VPN.
| Проверка | Запросы и раунды | Что позволяет увидеть | Чего не подтверждает |
|---|---|---|---|
| Standard | 6 запросов, 1 раунд | Какие резолверы обработали запросы в одном коротком сеансе | Стабильность маршрута при повторении |
| Extended | 36 запросов, 6 раундов | Меняется ли наблюдаемый набор резолверов в ходе нескольких раундов | Полную картину для всех программ и сетевых сценариев |
Количество серверов в выводе само по себе не является оценкой риска. Один настроенный DNS-резолвер может задействовать несколько серверов. И наоборот, один отображённый сервер не доказывает, что запросы прошли по желаемому маршруту. Значение имеют оператор и ожидаемая схема обработки.
Результат теста следует читать как снимок сетевого поведения. Если Standard и Extended показывают один и тот же ожидаемый маршрут, это усиливает уверенность в наблюдаемом сценарии. Но тест всё равно не доказывает отсутствие утечки в других приложениях, после смены сети или при разрыве VPN.
2. Установить, кому принадлежат резолверы
Рекурсивный резолвер получает DNS-запросы устройства. Поэтому выбор такого сервера имеет последствия для приватности: он может видеть значительную часть DNS-активности. Настройки сети и DHCP нередко определяют, какой резолвер использует устройство. При активном VPN ожидаемая схема может измениться, но принадлежность сервера нужно устанавливать по оператору, а не по внешнему виду названия.
Появление в результатах DNS-сервера домашнего интернет-провайдера считается признаком утечки в руководстве Proton VPN. Однако имя сторонней компании само по себе недостаточно для такого вывода. VPN может использовать внешнюю инфраструктуру для обработки запросов. В этом случае сервер принадлежит инфраструктурному подрядчику, но маршрут не обязательно возвращает DNS-запросы провайдеру домашнего доступа.
Для анализа сопоставьте три вещи:
- оператора, указанного в результатах теста;
- ожидаемую схему DNS, описанную для используемого VPN-клиента;
- текущие настройки устройства, включая вручную заданные DNS-серверы.
Если оператор совпадает с домашним провайдером, а VPN должен направлять DNS-запросы через собственный маршрут, результат требует проверки. Если отображается сторонняя инфраструктура, сначала выясните, использует ли её VPN. Без этой сверки нельзя надёжно отличить утечку от штатной обработки.
Название чужой компании в DNS-результате ещё не устанавливает утечку. Ключевой вопрос — кто получил запрос и соответствует ли это настроенному маршруту.
Полезно сохранить результаты Standard и Extended вместе с временем проверки и состоянием VPN. Это не полноценный сетевой аудит, но позволяет сравнивать наблюдения после изменения настроек. При несоответствии одного лишь веб-вывода может быть мало: для анализа трафика применяют анализатор сетевых протоколов на конечном устройстве либо исследуют сетевой трафик другим подходящим способом.
3. Проверить пользовательский DNS и DoH
Ручная настройка стороннего DNS может переопределить защиту от DNS-утечек в VPN. Если пользователь указал собственный резолвер в операционной системе, браузере или другом клиенте, фактический маршрут может отличаться от ожидаемого VPN-маршрута. Поэтому проверка не заканчивается на главном переключателе VPN: нужно выяснить, какие DNS-параметры заданы на устройстве и в приложениях.
Отдельный случай — DNS over HTTPS, или DoH. Протокол передаёт DNS-запросы и ответы через HTTPS. Его наличие не доказывает, что запросы идут через VPN. Это определяется конфигурацией маршрута и клиента. HTTPS описывает способ передачи DNS-данных между участниками соединения, но сам по себе не отвечает на вопрос, через какой сетевой интерфейс проходит соединение.
Практический порядок проверки такой:
1. Зафиксировать DNS-настройки операционной системы и активных приложений. Особое внимание требуется профилям, где резолвер задан вручную.
2. Проверить настройки самого VPN-клиента. Если он предлагает защиту DNS-запросов, сопоставить её с фактической конфигурацией устройства.
3. Выполнить тест при включённом VPN. Если ожидаемое поведение не подтверждается, временно проверить пользовательские DNS-настройки и повторить тест.
4. Оценивать результат после каждого изменения отдельно. Одновременная смена нескольких параметров затрудняет установление причины.
Отключать защитные функции на постоянной основе ради эксперимента не требуется. Цель диагностики — установить, какое правило маршрутизации действует, а не оставить устройство в промежуточной конфигурации. После теста параметры следует вернуть в выбранное состояние и повторно проверить результат.
Для общей защиты устройства DNS-маршрут — только один слой. При настройке системных параметров полезно учитывать и пять ключевых настроек безопасности устройства, поскольку они затрагивают другие поверхности риска, не проверяемые DNS-тестом.
4. Испытать kill switch при обрыве туннеля
Пока VPN-соединение активно, тест показывает поведение в штатном режиме. Сбой туннеля — другой сценарий. Если kill switch включён, нужно проверить, блокирует ли клиент доступ в интернет после разрыва и не появляются ли в этот момент нежелательные DNS-запросы.
Проверка строится вокруг контролируемого обрыва. Сначала включают kill switch и подключают VPN. Затем прерывают VPN-соединение, наблюдают за доступом в интернет и проверяют сетевое поведение. После этого туннель восстанавливают и убеждаются, что доступ возвращается. Такой сценарий рекомендован для оценки работы kill switch; сетевой анализ на конечном устройстве даёт больше данных, чем одно сообщение интерфейса о состоянии подключения.
Результат нужно трактовать буквально. Если интернет продолжает работать после обрыва VPN, это означает, что блокировка не сработала в данном сценарии либо настроена иначе. Если доступ прекращается, это подтверждает блокировку именно при проверенном разрыве. Ни один из этих исходов сам по себе не устанавливает поведение при каждом возможном сбое, после перезагрузки устройства или при переключении между Wi‑Fi и мобильной сетью.
После восстановления туннеля проверьте DNS-маршрут повторно. Возврат значка подключения не равен подтверждённому возврату прежней конфигурации. Клиент может восстановить туннель, а системные или пользовательские DNS-настройки останутся прежними. Здесь важна последовательность: обрыв, блокировка, переподключение, повторное наблюдение за DNS.
5. Отделить DNS от остальных утечек
Успешный DNS-тест не оценивает IP-утечку, WebRTC или split tunneling. Это отдельные свойства сетевого поведения. Например, браузерная проверка WebRTC относится к тому, какие сетевые сведения доступны через соответствующие механизмы браузера. Она не заменяет проверку DNS, а DNS-тест не отвечает на вопрос о WebRTC.
Для практической оценки полезно вести пять независимых наблюдений:
1. DNS в штатном режиме. Сравнить Standard и Extended и сопоставить операторов резолверов с ожидаемым маршрутом.
2. DNS после изменения конфигурации. Проверить влияние вручную заданного DNS и настроек приложений, включая DoH.
3. DNS при обрыве VPN. Убедиться, что kill switch блокирует соединение в проверенном сценарии, затем проверить поведение после восстановления туннеля.
4. IP и WebRTC. Запустить предназначенные для них отдельные проверки. Положительный DNS-результат не закрывает эти пункты.
5. Split tunneling. Установить, какие приложения направляются через VPN, а какие используют обычное соединение, и оценивать их отдельно.
Этот список не является признанной шкалой риска. Он помогает не смешивать разные типы утечек и не выдавать один удачный тест за общую гарантию приватности. Для проверки трафика на устройстве можно использовать анализатор сетевых протоколов; веб-сервис полезен как индикатор, но его область наблюдения ограничена созданными им запросами.
Риск DNS-утечки оценивается по соответствию фактического маршрута ожидаемой конфигурации, включая поведение при сбое. Если результаты показывают резолвер домашнего провайдера, настройки DNS требуют разбора. Если видна сторонняя инфраструктура, сначала устанавливают её роль. Если тест пройден, вывод ограничивается проверенным сеансом и запросами.
Ни 6, ни 36 запросов не подтверждают полную анонимность. Они дают данные для конкретной проверки. Жёсткий критерий здесь один: вывод должен соответствовать наблюдаемому маршруту, а не одному зелёному индикатору в интерфейсе.