Утечка DNS, WebRTC и IPv6: как проверить VPN и закрыть дыры

Человек пишет в поддержку: «VPN подключён, значок горит, страна в приложении немецкая. А сайт всё равно показывает мой город и предлагает доставку по моему адресу. Вы там серверы перепутали?»

Не перепутали. Просто туннель — одна труба, а данных о вас утекает наружу по нескольким, и три из них к самому туннелю отношения не имеют вообще, что для человека, заплатившего за VPN, звучит как издевательство, но устроено именно так. DNS, WebRTC, IPv6. Три дырки, через которые настоящий адрес уходит в мир при формально исправном VPN. Кнопкой «подключиться» ни одна не чинится. Хорошая новость: проверяется всё за пять минут, чинится за десять.

Сразу оговорюсь: я работаю в VPN-сервисе, так что читайте меня со скидкой. Впрочем, всё, о чём тут написано, проверяется одинаково на любом сервисе, включая мой: течём — увидите теми же пятью тестами.

Почему VPN работает, а IP всё равно светится

Открыть сайт — не одно действие, а цепочка. Сначала устройство спрашивает у DNS, какой адрес у имени. Потом устанавливает соединение. Попутно браузер выполняет собственные запросы, о которых вы не просили и, скорее всего, не подозреваете. И вдобавок у системы часто два независимых стека адресации, IPv4 и IPv6, каждый со своей маршрутизацией и своим мнением о том, куда ехать. VPN отвечает только за второй шаг: берёт пакеты и заворачивает в туннель. А запросы к DNS, инициатива браузера и вся шестая версия протокола могут спокойно пойти другой дорогой. Отсюда ответ на вопрос «почему виден мой IP при включённом VPN». Вернее, не так: не потому, что VPN плохой, а потому, что утекает не то, что он защищает.

Аналогия грубая, но рабочая, я ей пользуюсь года три: вы вышли из дома в маске и тёмных очках, но перед выходом громко спросили у консьержа дорогу, оставили на двери записку с телефоном и вышли через второй подъезд, о котором забыли. Маска на месте. Толку немного.

Кстати, о том, что вытаскивают из одного только IP, есть отдельный разбор.

[Изображение: схема трёх утечек на одной иллюстрации — DNS-запрос уходит к провайдеру, WebRTC отдаёт адрес напрямую сайту, IPv6-трафик идёт мимо туннеля]

Утечка DNS: провайдер видит все ваши домены

Самая частая и, по-моему, самая недооценённая.

DNS — телефонная книга интернета. Прежде чем подключиться к сайту, устройство спрашивает у DNS-сервера: какой адрес у такого-то имени? И вот здесь начинается интересное. Если VPN настроен правильно, вопрос уходит внутрь туннеля — на резолвер VPN-сервиса или на сторонний, до которого запрос доезжает зашифрованным. Настроен неправильно — вопрос идёт напрямую на DNS провайдера, мимо всего шифрования, и заметить это без проверки невозможно, потому что интернет при этом работает ровно так же хорошо. Что плохого? Содержимое страниц провайдер не увидит, там HTTPS. Зато увидит полный список доменов с точностью до минуты, и по нему составляется портрет: чем интересуетесь, чем болеете, где работаете. Скажем так, утечка DNS сливает не содержимое, а оглавление. Иногда этого более чем достаточно.

Откуда она берётся — вот четыре причины, которые я встречал чаще прочих:

• Система игнорирует DNS-серверы туннеля и использует прописанные в настройках адаптера. Классика Windows с её «умной» раскладкой запросов по всем интерфейсам сразу.
• В браузере включён DNS через HTTPS со своим сервером — он ходит в обход системных настроек и туннеля.
• В роутере жёстко прописаны DNS провайдера, и все устройства слушаются его.
• Раздельное туннелирование настроено так, что DNS попал в исключения. Бывает случайно.

То, что в англоязычных инструментах называют dns leak test, встроено в нашу страницу проверки соединения. Откройте её при включённом VPN и посмотрите блок с DNS. Имя домашнего провайдера — первая дырка найдена.

Утечка WebRTC: браузер сам называет ваш адрес

Эта дырка обиднее всех, потому что VPN тут вообще ни при чём, и я терпеть не могу её объяснять — виноватым всё равно назначают сервис. WebRTC — технология прямой связи между браузерами: видеозвонки без установки программ, голосовые чаты во вкладке, передача файлов. Вещь полезная, встроена во все браузеры и включена по умолчанию. Чтобы соединить два браузера напрямую, каждый должен знать, как до него достучаться, и для этого есть механизм STUN: браузер обращается к внешнему серверу и спрашивает — а как я выгляжу снаружи? Заодно перечисляет все локальные адреса. Проблема в том, что эти запросы идут в обход обычного сетевого стека и могут не попасть в туннель, и тогда любая страница с парой строчек скрипта получает и локальный адрес, и публичный — настоящий. Вот это и есть утечка WebRTC. Тихо, без разрешений; ни значка, ни уведомления.

Неприятный бонус — сопоставление. Сайт видит сразу и адрес VPN-сервера в заголовках, и ваш реальный из WebRTC. Вывод напрашивается сам: вот человек с VPN, и вот его настоящий IP. Для антифрода это готовый сигнал, и, по моему опыту, отсюда растёт половина историй про «меня забанили, хотя я ничего не делал».

Утечка IPv6: вторая дверь, про которую забыли

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

Решений два: либо туннель умеет IPv6 и заворачивает его тоже, либо шестую версию отключают на устройстве или роутере. Первое лучше, второе проще. Я делаю второе, каюсь.

Всем ли подряд надо отключать IPv6? Нет. Провайдер его не выдаёт — выключать нечего. Проверить принадлежность своего адреса и заодно посмотреть, не числится ли он в чёрных списках, можно на странице проверки IP.

Утечка при обрыве и почему Kill Switch — не панацея

Четвёртый сценарий, особняком. Туннель падает — на секунду, на три, на время переключения между Wi-Fi и мобильной сетью. Система возвращает маршрут по умолчанию на обычный интерфейс, и трафик мгновенно идёт открытым, а вы не замечаете, потому что переподключение быстрее, чем взгляд на экран. Против этого работает Kill Switch: блокирует сеть, пока туннель не поднимется. Штука обязательная, и как убедиться, что она включена по-настоящему, разобрано в статье про Kill Switch. Но вот что постоянно путают, и я сам когда-то путал. Kill Switch закрывает одну дыру из четырёх — ту, что открывается при обрыве. Он не мешает DNS уходить провайдеру, не мешает браузеру отдать адрес через STUN, не заворачивает IPv6.

Включённый Kill Switch — это не «я защищён», а «одна из четырёх проблем решена».

Пять тестов за пять минут

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

1. Базовый адрес. Подключите VPN и откройте проверку соединения. Смотрите на IP и страну: они должны совпадать с выбранным сервером, а не с вашим городом.
2. DNS. На той же странице найдите блок с DNS-серверами. Там должны быть адреса VPN-сервиса или публичного резолвера. Название домашнего провайдера — утечка.
3. WebRTC. Смотрите блок с адресами из WebRTC. В норме там либо пусто, либо адрес VPN-сервера. Появился ваш настоящий публичный IP — дырка есть. Локальные адреса вида 192.168.x.x критичной утечкой не считаются.
4. IPv6. Показан IPv6-адрес, не относящийся к VPN-серверу, — трафик по шестой версии идёт мимо туннеля.
5. Обрыв. Аварийно оборвите связь: выключите Wi-Fi на несколько секунд или снимите процесс клиента. Сразу обновите страницу. Не открылась — Kill Switch работает. Показала реальный адрес — нет.

Прогнать стоит на каждом устройстве и в каждом браузере. Результаты отличаются, иногда до смешного: Chrome течёт, Firefox нет, на телефоне чисто, на ноутбуке беда.

[Изображение: два результата проверки рядом — слева «плохой» с реальным IP в блоке WebRTC и DNS провайдера, справа «хороший», где все три блока показывают адреса VPN-сервера]

Как это чинить

По каждой дыре отдельно. Порядок мой, можно и в другом.

DNS

Сначала настройки клиента: почти во всех есть опция вроде «Использовать DNS VPN» или «Защита от DNS-утечек». Включите. В половине случаев на этом всё и заканчивается — и, если честно, мне каждый раз неловко, когда человек полдня копал маршруты, а потом находит эту галочку. Не помогло — пропишите DNS вручную в свойствах адаптера, указав серверы, доступные только через туннель. На роутере то же самое, если раздача идёт оттуда. И обязательно проверьте браузер: в Chrome и Firefox есть своя настройка защищённого DNS, которая живёт отдельной жизнью и обходит систему. Либо выключите, либо укажите тот же резолвер.

WebRTC

Firefox. Самый прямой путь. В адресной строке about:config, соглашаетесь с предупреждением, ищете media.peerconnection.enabled и переводите в false. Видеозвонки в браузере после этого работать перестанут — учитывайте.

Chrome. Встроенного выключателя нет и не планируется. Как отключить WebRTC в Chrome: либо расширением, ограничивающим выдачу адресов, либо — на рабочей машине — политикой управления браузером. Расширения берите только из официального магазина и с внятной репутацией, иначе лечение выйдет хуже болезни.

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

Safari. Здесь спокойнее, и мне он в этом смысле нравится: браузер по умолчанию маскирует локальные адреса и спрашивает разрешение на доступ к медиаустройствам. Полностью выключить механизм можно через меню «Разработка», которое сначала надо включить в настройках. Большинству это не нужно.

IPv6

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

Простой вариант — отключить. На Windows это галочка в свойствах адаптера, на macOS — конфигурация IPv6 в положение «Выключено», на роутере — отдельный пункт в разделе подключения к провайдеру. Вариант с роутером лучше: закрывает вопрос сразу для всех устройств в доме.

[Изображение: пошаговые скриншоты отключения WebRTC — about:config в Firefox и окно расширения в Chrome]

Как читать результат: что нормально, а что тревожно

Проверку прогнали, теперь надо понять, что вы видите. Разложу по светофору.

И о том, из-за чего тревожиться не стоит. Несовпадение города внутри страны сервера — нормально, геобазы врут постоянно. Капча на каждом шагу — не утечка, а репутация общего адреса, лечится выделенным IP. Российские сайты, которые не открываются, — тоже не утечка. Ладно, а если после всех правок тест по-прежнему показывает странное — не гадайте, напишите в поддержку со скриншотом. Разбирается за один диалог.

Что запомнить

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

Проверьте свой VPN за тридцать секунд — тест покажет IP, DNS, WebRTC и IPv6 на одной странице. Течёт — выше написано, как чинить. VPN ещё нет — четырнадцать дней теста без карты, и первое, что стоит сделать после подключения, это как раз прогнать проверку.

Частые вопросы

Что такое утечка DNS?

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

Как проверить утечку WebRTC?

Подключите VPN, откройте страницу проверки и найдите блок с адресами из WebRTC. Там ваш настоящий публичный IP вместо адреса VPN-сервера — утечка есть. Проверять нужно в каждом браузере отдельно: у Chrome, Firefox и Safari результаты различаются.

Почему при VPN виден мой настоящий IP?

Три основные причины: DNS-запросы идут мимо туннеля, браузер раскрывает адрес через WebRTC, трафик по IPv6 уходит напрямую, потому что туннель поднят только для IPv4. Четвёртый вариант — короткий обрыв без работающего Kill Switch. Все проверяются последовательно, за пять минут.

Нужно ли отключать IPv6?

Только если ваш VPN не умеет туннелировать шестую версию, а провайдер её выдаёт. Тогда трафик к сайтам с IPv6 пойдёт мимо туннеля с вашим реальным адресом. Лучше взять сервис, который заворачивает обе версии; отключение IPv6 на роутере или в системе закрывает вопрос грубым способом.