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

Не каждый незнакомый адрес DNS-сервера означает утечку. VPN-провайдер может использовать anycast, облачный резолвер или split DNS для отдельных доменов. Сначала нужно определить ожидаемую схему: какой резолвер должен обслуживать обычные и внутренние зоны и через какой интерфейс к нему должен идти трафик.

Как проявляется DNS leak

  • После подключения VPN тест показывает DNS-сервер интернет-провайдера.
  • Внешний IP изменился, но DNS-запросы продолжают идти через локальный шлюз.
  • Внутренние домены VPN открываются, а обычные имена разрешаются локальной сетью.
  • Один браузер использует другой DNS, чем остальные приложения.
  • После сна, смены Wi-Fi или переподключения VPN системный DNS возвращается к прежнему серверу.
  • IPv4-запросы идут через туннель, а IPv6-трафик обходит его.
  • При одновременной работе корпоративного и личного VPN правила DNS конфликтуют.

Определите, что именно должно происходить

До проверки сформулируйте ожидаемую политику. Для полного туннеля обычно все обычные DNS-запросы должны обслуживаться выбранным резолвером через VPN. Для split tunneling часть доменов может намеренно идти к корпоративному DNS, а остальные — к другому серверу.

  • Какой DNS-сервер выдает VPN-клиент.
  • Доступен ли этот сервер только через туннель или через интернет.
  • Какие доменные зоны должны использовать отдельный корпоративный резолвер.
  • Разрешен ли DNS over HTTPS в браузере и какой провайдер выбран.
  • Должен ли VPN маршрутизировать IPv6 или только IPv4.
  • Какие локальные имена должны оставаться доступными вне туннеля.

Проверяйте не только публичным сайтом

Онлайн-тест полезен как первый сигнал, но он видит только запросы, которые браузер отправил к тестовым доменам. Результат может зависеть от кэша, DoH, расширений и архитектуры самого теста. Нужна проверка системного резолвера и маршрута к нему.

  1. Очистите только DNS-кэш тестового устройства, если это безопасно для среды.
  2. Подключите VPN и запишите выданные DNS-настройки.
  3. Выполните запрос через системный резолвер, а не только из браузера.
  4. Проверьте маршрут до адреса DNS-сервера.
  5. Сравните результат с браузером, где может работать собственный DoH.
  6. Повторите тест после переподключения, сна и смены сети.

Системный DNS и приоритет интерфейсов

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

  • Проверьте порядок DNS-серверов и метрики сетевых интерфейсов.
  • Убедитесь, что VPN-профиль применяет настройки к нужному подключению.
  • Ищите одновременно активные клиенты VPN, виртуальные адаптеры и корпоративные агенты.
  • Проверьте правила доменных зон, а не только общий список серверов.
  • Учитывайте, что NetworkManager, systemd-resolved и другие менеджеры могут перезаписать ручные изменения.

Браузерный DNS over HTTPS

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

  • Сравните результат браузера и системной утилиты разрешения имен.
  • Проверьте настройки Secure DNS или DoH в каждом браузере.
  • Не отключайте DoH автоматически: сначала определите требуемую модель доверия.
  • Для корпоративного split DNS настройте совместимость, иначе внутренние домены могут перестать открываться.
  • Учитывайте приложения, которые используют собственный DoH независимо от браузера.

IPv6 часто остается вне туннеля

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

  • Проверьте наличие IPv6-адреса и default route после подключения VPN.
  • Убедитесь, что VPN поддерживает и маршрутизирует IPv6 согласно политике.
  • Если IPv6 не используется, отключение должно быть осознанным и проверенным на всех интерфейсах, а не случайным костылем.
  • Проверьте DNS-серверы, доступные по IPv6, и браузерные соединения к DoH.
  • Повторите тест после смены сети, где IPv6 может появиться впервые.

Split DNS не всегда является утечкой

В корпоративной сети запросы к внутренней зоне должны идти к корпоративному DNS, а публичные домены могут обслуживаться другим резолвером. Это нормальный split DNS, если правило явно задано и запросы не попадают случайному провайдеру.

  • Закрепите внутренние зоны за конкретным резолвером.
  • Не отправляйте все запросы локальному DNS только ради доступа к одному внутреннему имени.
  • Проверьте поведение для поддоменов и совпадающих суффиксов.
  • Учитывайте поиск коротких имен и DNS search domains.
  • Документируйте, какие запросы намеренно выходят за пределы полного туннеля.

Маршрут к DNS-серверу

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

  • Проверьте выбранный интерфейс и next hop для адреса резолвера.
  • Убедитесь, что маршрут создается при подключении и удаляется при отключении.
  • Исключите конфликт одинаковых подсетей дома и внутри VPN.
  • Проверьте policy routing и отдельные таблицы маршрутов клиента.
  • Не полагайтесь только на default route, если используются более специфичные правила.

Кэш может исказить результат

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

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

Как исправить DNS leak

  1. Назначьте ожидаемый DNS-резолвер в VPN-профиле или клиенте.
  2. Настройте приоритет интерфейсов и область доменных зон.
  3. Добавьте маршрут к DNS-серверу через VPN, если он не формируется автоматически.
  4. Согласуйте браузерный DoH с политикой VPN и внутренними доменами.
  5. Настройте IPv6 через туннель либо явно закройте неподдерживаемый путь после проверки требований.
  6. При полном туннеле ограничьте прямые DNS-запросы вне VPN на уровне клиента или шлюза.
  7. Проверьте восстановление безопасных настроек после reconnect, сна и смены сети.

Ограничение прямых DNS-запросов

Kill switch или firewall может запретить обращения к DNS вне VPN. Такое правило должно учитывать адреса резолвера, IPv4 и IPv6, локальные сервисы, DoH и момент подключения. Ошибка в правиле способна полностью сломать разрешение имен.

  • Сначала проверьте правило на тестовом устройстве с возможностью отката.
  • Разрешайте только необходимые направления и интерфейсы.
  • Не блокируйте служебный доступ, требуемый самому VPN для установления соединения.
  • Учитывайте captive portal в публичной сети до подключения туннеля.
  • Проверяйте, что после аварийного отключения VPN политика соответствует ожидаемому fail closed или fail open.

DNSSEC не устраняет утечку

DNSSEC помогает проверить подлинность DNS-ответа для подписанной зоны, но не скрывает запрос от резолвера и не меняет маршрут. DoT и DoH шифруют канал до выбранного DNS-сервера, однако сервер все равно видит запросы. Нужно отдельно решать целостность, шифрование и выбор доверенного маршрута.

Пошаговая диагностика

  1. Запишите ожидаемый резолвер и правила split DNS.
  2. Подключите VPN и проверьте системные DNS-настройки.
  3. Определите маршрут до каждого DNS-сервера по IPv4 и IPv6.
  4. Сравните системный запрос, браузер с DoH и другое приложение.
  5. Проверьте пакеты или безопасные журналы на интерфейсах без записи содержимого пользовательского трафика.
  6. Повторите тест после reconnect, сна, смены Wi-Fi и включения мобильной сети.
  7. Изменяйте один уровень за раз и фиксируйте результат.

Как проверить результат

  • Системные запросы идут только к ожидаемому резолверу.
  • Маршрут к нему проходит через нужный VPN-интерфейс.
  • IPv4 и IPv6 соответствуют одной политике.
  • Браузерный DoH либо согласован с политикой, либо отключен осознанно.
  • Внутренние зоны открываются через корпоративный DNS, а публичные — по заданному правилу.
  • После переподключения старый DNS провайдера не возвращается.
  • При падении VPN система ведет себя согласно выбранному fail closed или fail open.

Типичные ошибки

  • Считать любой публичный DNS в тесте утечкой без знания архитектуры VPN.
  • Проверять только внешний IP и не смотреть DNS-маршрут.
  • Отключать IPv6 в одном месте, оставляя его активным на другом интерфейсе.
  • Менять resolv.conf вручную, хотя его перезаписывает сетевой менеджер.
  • Игнорировать Secure DNS в браузере.
  • Блокировать все DNS-запросы и не разрешить резолверу VPN работать.
  • Использовать DNSSEC как замену маршрутизации и шифрованию.

Как предотвратить повторение

  • Храните DNS и маршруты в управляемом VPN-профиле, а не в ручных настройках пользователя.
  • Добавьте автоматический тест после подключения и изменения сети.
  • Проверяйте IPv4, IPv6, DoH и split DNS отдельно.
  • Документируйте ожидаемые резолверы и исключения.
  • Обновляйте VPN-клиент и сетевой менеджер с проверкой поведения DNS.
  • Мониторьте невозможность разрешить внутренние зоны и появление неожиданных серверов.

Итог

DNS leak через VPN нужно подтверждать не одним сайтом, а проверкой системного резолвера, маршрута, браузерного DoH и IPv6. После определения ожидаемой политики настройте DNS в VPN-профиле, маршрут до резолвера и защиту от прямых запросов, затем протестируйте reconnect и смену сети.

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