Что такое DNS-запрос и почему он важен для приватности
Каждый раз, когда браузер обращается к сайту по доменному имени, система отправляет DNS-запрос — обращение к резолверу с просьбой преобразовать имя в IP-адрес. Этот запрос содержит доменное имя в открытом виде и уходит до того, как устанавливается соединение с целевым сервером.
Для наблюдателя на уровне сети — интернет-провайдера, администратора корпоративной сети, оператора точки доступа — DNS-запросы представляют собой подробный журнал посещений. Даже если сам трафик к сайту зашифрован через HTTPS, факт обращения к конкретному домену виден из DNS. По набору доменов можно восстановить профиль интересов пользователя, определить используемые сервисы, а в некоторых случаях — конкретные страницы или API-endpoint'ы.
DNS-запрос по умолчанию передаётся по UDP на порт 53. Это означает, что содержимое запроса не шифруется и не аутентифицируется — любой узел на пути может его прочитать или подменить ответ. Именно эта открытость делает DNS-запросы удобным каналом утечки при использовании VPN.
Механизм утечки
VPN-туннель шифрует и перенаправляет IP-пакеты через удалённый сервер. Однако DNS-запросы — это тоже IP-пакеты, и они подчиняются тем же правилам маршрутизации. Утечка возникает, когда DNS-запрос минует туннель и уходит напрямую к резолверу, назначенному операционной системой или DHCP-сервером провайдера.
Типичные причины:
- ОС не перенаправляет DNS через туннель. VPN-клиент изменил маршрут для основного трафика, но DNS-резолвер остался прежним — тот, что выдал провайдер. Запросы уходят вне туннеля.
- Раздельная маршрутизация (split tunneling). Часть трафика намеренно идёт мимо VPN для скорости или доступа к локальным ресурсам. Если DNS-запросы попадают в эту категорию, они видны провайдеру.
- IPv6. Если VPN-туннель обрабатывает только IPv4, а система отправляет DNS-запросы по IPv6, они уходят напрямую.
- Сбой туннеля. При кратковременном разрыве соединения ОС может переключиться на резервный резолвер до того, как туннель восстановится.
- Приоритет интерфейсов. В системах с несколькими сетевыми интерфейсами (Wi-Fi + Ethernet, или физический интерфейс + виртуальный туннель) DNS-резолвер может быть привязан к интерфейсу с более высоким приоритетом, который не является VPN-туннелем.
Результат во всех случаях одинаков: IP-адрес скрыт за VPN-сервером, но список посещённых доменов доступен тому, кто контролирует DNS-резолвер или перехватывает трафик на пути к нему. Это сводит на нет основную цель использования VPN — анонимизацию.
Как маршрутизация WireGuard влияет на DNS
WireGuard работает как сетевой интерфейс (wg0, wg1 и т. д.), через который инкапсулируются IP-пакеты поверх UDP. Ключевой механизм — Cryptokey Routing: каждому пиру назначается список AllowedIPs, который одновременно служит таблицей маршрутизации для исходящих пакетов и списком контроля доступа для входящих.
Когда в конфигурации клиента указан
AllowedIPs = 0.0.0.0/0, это означает, что все IP-пакеты с любым адресом назначения будут зашифрованы и отправлены через туннель. В таком режиме DNS-запросы тоже попадают в туннель, потому что они являются обычными IP-пакетами. Значение 0.0.0.0/0 выступает как wildcard — оно покрывает весь диапазон IPv4-адресов.Однако если AllowedIPs содержит только подсеть VPN-сервера (например, 10.0.0.0/24), а не 0.0.0.0/0, то DNS-запросы к внешнему резолверу не будут маршрутизированы через интерфейс WireGuard и уйдут напрямую. Это происходит потому, что при отправке пакета WireGuard сверяет адрес назначения со списком AllowedIPs каждого пира: если адрес не попадает ни в один диапазон, пакет отбрасывается интерфейсом и уходит через обычный сетевой стек.
WireGuard поддерживает любую комбинацию IPv4 и IPv6 в полях конфигурации, включая AllowedIPs. Если в списке указаны только IPv4-диапазоны, IPv6-пакеты (включая DNS-запросы по IPv6) не будут маршрутизированы через туннель.
Network namespaces как гарантия изоляции
Дополнительный уровень изоляции даёт работа с сетевыми пространствами имён (network namespaces). WireGuard отправляет и принимает пакеты в том namespace, где был создан интерфейс. Это позволяет создать интерфейс WireGuard в основном namespace с доступом к интернету, а затем переместить его в namespace контейнера или отдельного процесса.
В такой конфигурации единственный способ выхода в сеть для изолированного процесса — через туннель. DNS-запросы физически не могут миновать интерфейс WireGuard, потому что других сетевых интерфейсов в namespace нет. Этот подход применяется, например, при запуске контейнеров Docker, где WireGuard-интерфейс становится единственным сетевым интерфейсом контейнера.
DNS over HTTPS как дополнительный слой
DNS over HTTPS (DoH) шифрует DNS-запросы, оборачивая их в обычные HTTPS-запросы. Трафик идёт через порт 443 — тот же, что и стандартный веб-трафик. Это делает DNS-запросы неотличимыми от любого другого HTTPS-соединения на уровне сети.
DoH поддерживает протоколы HTTP, HTTP/2 и HTTP/3. Даже если DNS-запрос каким-то образом покинул VPN-туннель, наблюдатель увидит лишь HTTPS-соединение с сервером DoH-провайдера, но не содержимое запроса и не целевой домен. Шифрование предотвращает подмену и перехват DNS-ответов.
Важно понимать ограничения DoH:
- DoH защищает содержимое DNS-запроса, но не скрывает факт обращения к DoH-серверу. Наблюдатель видит HTTPS-соединение с известным DoH-провайдером.
- DoH не меняет IP-адрес источника запроса. Без VPN ваш реальный IP остаётся видимым для DoH-сервера.
- DoH не защищает от утечки через другие каналы (WebRTC, прямые IP-соединения приложений).
DoH не заменяет VPN, а дополняет его. VPN скрывает IP-адрес и маршрутизирует трафик, DoH защищает содержимое DNS-запросов от перехвата. Вместе они закрывают оба канала утечки.
Как обнаружить DNS-утечку
Принцип проверки прост: существует класс онлайн-сервисов, которые при обращении показывают, какой DNS-резолвер обработал запрос. Если VPN активен, а сервис показывает резолвер вашего интернет-провайдера или резолвер, географически привязанный к вашему реальному местоположению, — утечка есть.
Алгоритм проверки:
- Подключите VPN и убедитесь, что туннель установлен.
- Откройте сервис проверки DNS-утечек в браузере.
- Запустите тест — сервис отправит несколько DNS-запросов и покажет, какие резолверы их обработали.
- Сравните результат: если все резолверы принадлежат VPN-провайдеру или нейтральным сервисам, утечки нет. Если виден резолвер вашего ISP — проблема подтверждена.
Для полноты картины стоит повторить тест несколько раз и в разных условиях:
- При переподключении VPN.
- При переключении между Wi-Fi и мобильной сетью.
- После сна или гибернации устройства.
- При смене DNS-сервера в настройках ОС.
- С включённым и выключенным DoH в браузере.
Некоторые сервисы проверки также тестируют IPv6-запросы отдельно. Если ваш VPN не обрабатывает IPv6, а система имеет IPv6-адрес, тест покажет утечку именно по IPv6.
Типичные ошибки при настройке
Неполный AllowedIPs в WireGuard. Если конфигурация клиента содержит только подсеть туннеля, а не 0.0.0.0/0, DNS-запросы к внешним резолверам не пойдут через интерфейс. Проверьте, что AllowedIPs покрывает весь трафик, если цель — полная маршрутизация через VPN. Для IPv6 аналогично должен быть указан диапазон ::/0.
Игнорирование IPv6. Если система имеет IPv6-адрес и VPN не обрабатывает IPv6-трафик, DNS-запросы могут уходить по IPv6 мимо туннеля. Решение — либо обеспечить маршрутизацию IPv6 через VPN (добавив ::/0 в AllowedIPs), либо отключить IPv6 на уровне интерфейса.
Отсутствие kill switch. При обрыве туннеля трафик, включая DNS, может пойти напрямую. Механизм kill switch блокирует сетевой доступ до восстановления туннеля. Без него даже кратковременный разрыв соединения приводит к утечке.
Доверие к DNS-настройкам VPN-клиента без проверки. Некоторые VPN-клиенты заявляют о защите от DNS-утечек, но реализация зависит от платформы и версии. Проверка через внешний сервис — единственный способ убедиться.
Конфликт резолверов. Если в системе настроено несколько DNS-резолверов (например, один от VPN-клиента, другой от DHCP), ОС может использовать любой из них в зависимости от приоритета интерфейса. Убедитесь, что после подключения VPN системный резолвер действительно указывает на сервер внутри туннеля.
DoH только в браузере. Если DoH включён только в настройках браузера, другие приложения (мессенджеры, системные обновления, фоновые сервисы) продолжают отправлять DNS-запросы через системный резолвер без шифрования. Для полной защиты DoH нужно настраивать на системном уровне или использовать VPN, который маршрутизирует весь трафик.
Практический чек-лист
- Убедитесь, что VPN-туннель маршрутизирует весь трафик (в случае WireGuard — AllowedIPs = 0.0.0.0/0 и, при необходимости, ::/0 для IPv6).
- Проверьте, обрабатывается ли IPv6-трафик через туннель или отключён на уровне интерфейса.
- Используйте DoH на уровне браузера или системного резолвера как дополнительный слой шифрования DNS.
- Проведите тест на DNS-утечку после настройки и периодически повторяйте его в разных условиях.
- Если VPN-клиент поддерживает kill switch — включите его.
- При использовании WireGuard в контейнерах или изолированных процессах применяйте network namespace для гарантии, что весь трафик проходит через туннель.
- Проверьте, что системный DNS-резолвер после подключения VPN указывает на сервер внутри туннеля, а не на резолвер провайдера.
- Если используете DoH, убедитесь, что он настроен не только в браузере, но и для системных запросов — иначе приложения вне браузера остаются уязвимы.
