DNS leak test: что он проверяет и как закрыть утечку

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

VPN пропускает трафик через шифрованный туннель и даёт другой адрес на выходе. И то и другое заметно: сайты показывают новый IP, провайдер видит шифрованный поток к одному хосту. Незаметна маленькая часть соединения, которая часто отказывается идти в туннель, — запрос имени, происходящий перед каждым обращением. Если он ускользает, у провайдера остаётся хронологический список всех открытых доменов с отметками времени, хотя прочитать он не может ни байта. Это и есть утечка DNS — самый распространённый способ раскрыться при исправно подключённом VPN.

Зачем вообще нужен DNS

Компьютеры маршрутизируют по числам, люди ориентируются по именам. Когда вы вводите домен, устройство просит резолвер превратить имя в IP-адрес и только потом открывает соединение. Запрос маленький, происходит перед каждым новым подключением и исторически идёт открытым текстом по порту 53.

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

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

Как на самом деле работает тест

Понимание механики делает результат читаемым. Страница теста генерирует набор уникальных случайных имён в своём домене — что-то вроде a1b2c3.test.example.com — и просит браузер загрузить с каждого ресурс. Имя уникально и никогда раньше не запрашивалось, поэтому ответа нет ни в одном кэше мира, и запрос обязан дойти до авторитетного сервера самого теста.

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

Чтение результата сводится к одному вопросу: эти резолверы принадлежат вашему VPN — или среди них есть провайдер либо мобильный оператор? Одна строка с именем вашего провайдера означает утечку, как бы правильно ни выглядело остальное. Наша проверка запускает этот тест вместе с IP и WebRTC на cyphervpn.net/check.html и ничего не сохраняет.

• Открывающиеся страницы — не доказательство работающего туннеля. Утечка DNS ничего видимого не ломает; именно поэтому она живёт годами.

Причина первая: в конфиге не задан резолвер

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

Как проверить: откройте файл конфигурации или свойства туннеля в клиенте и найдите строку DNS. Её нет — это и есть утечка.

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

Причина вторая: Windows спрашивает все адаптеры сразу

В Windows есть механизм smart multi-homed name resolution. Вместо отправки запроса резолверу активного интерфейса система шлёт его резолверам всех интерфейсов параллельно и берёт самый быстрый ответ. Резолвер провайдера физически ближе, чем тот, что за туннелем, поэтому обычно выигрывает — и в любом случае пишет запрос в журнал.

Это самая частая причина на Windows, и система делает ровно то, что задумал Microsoft. Оптимизация скорости, придуманная до того, как один из интерфейсов стал границей приватности.

Что делать: использовать клиент, который отключает это поведение на время подключения, либо выключить через групповые политики: Конфигурация компьютера, Административные шаблоны, Сеть, DNS-клиент, включить параметр отключения smart multi-homed name resolution. После этого перепроверьте — изменение не всегда применяется до пересоздания туннеля.

Причина третья: IPv6 обходит IPv4-туннель

Многие туннели передают только IPv4. Если у соединения есть рабочий IPv6, всё, что разрешается по нему, уходит обычным путём мимо туннеля. И утекает здесь больше, чем DNS: сам трафик идёт незащищённым и показывает ваш настоящий адрес.

Как проверить: тест, который показывает отдельно результат по IPv4 и IPv6, где во второй строке стоит ваш провайдер, демонстрирует именно это.

Что делать: взять конфиг, где разрешённые адреса покрывают обе версии протокола — для WireGuard это AllowedIPs со значением 0.0.0.0/0 вместе с ::/0. Наши идут именно так. Если провайдер поддерживает только IPv4, альтернатива — отключить IPv6 на адаптере на время работы VPN: грубо, но действенно.

Причина четвёртая: у браузера свой DNS

Современные браузеры умеют сами выполнять DNS поверх HTTPS, полностью минуя операционную систему. И Chrome, и Firefox это поддерживают, а в некоторых регионах и сетях включают по умолчанию. Когда режим активен, запросы браузера уходят в Cloudflare, Google или NextDNS независимо от того, что настроил ваш VPN.

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

Что делать: в Firefox — Настройки, Приватность и защита, отключить DNS через HTTPS, если резолверу вашего VPN вы доверяете. В Chrome параметр лежит в разделе Конфиденциальность и безопасность, Безопасность, «Использовать безопасный DNS». После отключения браузер возвращается к системному резолверу, которым управляет туннель.

Порядок проверки, который экономит время

Выполняйте по шагам, перепроверяя между ними: устранение одной причины часто меняет то, что покажет следующий тест.

• Тест при выключенном VPN. Запишите, какие резолверы видны. Это ваша базовая линия и одновременно то, как выглядит утечка.
• Подключитесь и повторите. Все резолверы из базовой линии должны исчезнуть. Если какой-то остался — вот она, утечка, и вы уже знаете, за каким резолвером идти.
• Отдельно посмотрите строку IPv6. Провайдер в результате по IPv6 — это вторая причина, и она серьёзнее, чем утечка одного DNS.
• Отключите безопасный DNS в браузере и повторите. Если список резолверов изменился, значит браузер всё это время разрешал имена сам.
• Перезагрузитесь и проверьте ещё раз. Часть утечек проявляется только на свежем подключении, пока клиент не успел применить настройки.

• Три проверки на одной странице.IP-адрес, WebRTC и DNS — прямо в браузере. Ничего не сохраняется, регистрироваться негде.Открыть проверку ->

Структурное решение

Всё выше лечит симптомы на вашем устройстве. Вторая половина задачи — на стороне провайдера, и именно она определяет, чего стоят ваши исправления.

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

Надёжнее схема, где выходная машина резолвит DNS сама. Запрос не покидает туннель, не доходит до публичного резолвера и не становится ничьим журналом. Так устроены наши выходы, и политика на cyphervpn.net/privacy.html описывает это подробно, включая два места, где данные всё-таки существуют.

FAQ

Что именно раскрывает утечка DNS?

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

Утечка DNS означает, что VPN сломан?

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

Насколько надёжен DNS leak test?

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

Спасёт ли kill switch от утечки DNS?

Сам по себе нет. Kill switch блокирует трафик при падении туннеля, а утечка DNS происходит при совершенно здоровом туннеле. Это разные сбои, и нужны оба механизма.

Достаточно ли шифрованного DNS в браузере?

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

• DNS, который не покидает туннель.Наши выходы резолвят DNS на самой машине. Без аккаунта и почты, оплата криптой от $1.99 за неделю.Получить Cypher VPN ->Telegram: t.me/CypherESIM_bot