WebRTC: утечка, которую VPN не закрывает

У вас крепостная дверь. Бронированные окна. Сигнализация на каждом этаже. Вы купили VPN, врубили шифрование, весь трафик идёт по защищённому туннелю. Вы в безопасности.

А в стене есть лаз для собаки. Он выходит прямо на улицу. Через него любой прохожий может нагнуться и увидеть вашу гостиную. Лаз нужен, чтобы пёс выбегал на прогулку. Но пёс не единственный, кто им пользуется.

Пёс это видеозвонки. Лаз это WebRTC. Он встроен в каждый современный браузер. Он открыт по умолчанию. И в отличие от камеры или микрофона, вашего разрешения никто не спрашивает.

В январе 2015 года Дэниел Рёслер выложил proof-of-concept: страничка с двадцатью строчками JavaScript, и настоящий IP-адрес VPN-пользователя появляется на экране. Сообщество безопасности отреагировало по классике: шок, гнев, баг-репорты. Только это был не баг. Это был by design. Десять лет прошло, а лаз всё ещё открыт.

Коротко: WebRTC отправляет UDP-запросы к STUN-серверам в обход VPN-туннеля, выставляя ваш настоящий IP на показ. Разрешение не требуется. Это не баг, это архитектура.

Как лаз устроен

WebRTC создан для peer-to-peer связи: видеозвонки, голос, передача файлов. Чтобы два компьютера нашли друг друга в сети, протокол использует ICE, он же Interactive Connectivity Establishment. ICE перебирает все доступные пути и выбирает лучший.

Эти пути называются кандидатами. Их четыре типа:

host означает ваш локальный IP. 192.168.1.42. Прямой слепок вашей домашней сети.

srflx, он же server reflexive, это ваш публичный IP, обнаруженный через STUN-сервер. STUN-запрос уходит по UDP. VPN-туннель? Proxy? SOCKS5? UDP идёт мимо них всех. Напрямую. Ваш настоящий IP приходит в ответе.

relay направляет через TURN-сервер. Самый безопасный вариант. Самый медленный. Почти никогда не стоит по умолчанию.

prflx, он же peer reflexive, всплывает при проверке связи между пирами.

Суть: STUN-запрос это UDP-пакет, который браузер шлёт за пределы VPN-туннеля. Без спроса. Без уведомления. Веб-страница вызывает RTCPeerConnection, браузер послушно опрашивает STUN-серверы, и все собранные IP складываются в объект ICE candidates, доступный из JavaScript. Двадцать строчек кода Рёслера работают и в 2025 году.

VPN-туннели шифруют TCP. SOCKS5-прокси маршрутизируют TCP. А STUN ходит по UDP и обходит оба. Это подтверждено и в 2018-м, и в 2025-м: SOCKS5 против WebRTC как мёртвому припарка. Браузерные VPN-расширения? Текут, пока WebRTC не заблокирован руками. Юзеры Reddit r/Adguard обнаружили это заново в сентябре 2025-го. День сурка, только с IP-адресами.

В 2025 году Koysha et al. опубликовали кросс-платформенное исследование на arXiv:2510.16168: замеры утечек WebRTC в актуальных билдах Chrome, Brave, Firefox и Tor Browser на десктопе и мобилках. В той же работе авторы показали атаку через полудоверенную Wi-Fi-сеть: ICE-кандидаты молча раскрыли внутреннюю топологию сети. Без взаимодействия с пользователем. Без дополнительного софта. Просто открытая веб-страница.

Кто течёт, кто нет

Браузер	Десктоп	Мобильный
Chrome	Метаданные текут: mDNS стоит вместо IP, но foundation-атрибут пробивается	LAN-адреса и CGNAT-адреса утекают открыто
Brave	Прямых утечек IP нет, но mDNS-токены стабильны в рамках сессии	Аналогично десктопу
Firefox	Крепкая защита	Android: внутренние IP утекают
Tor Browser	Полная блокировка всех утечек	Полная блокировка всех утечек

Chrome лидирует в худшую сторону. На мобильных он сливает не только локальные адреса, но и CGNAT-адреса из диапазона 100.64.0.0/10. Это адреса оператора связи. По ним определяется мобильный провайдер и приблизительное местоположение внутри его сети. При этом мобильный Chrome даже не позволяет выключить WebRTC через встроенные настройки.

Главный вывод из исследования 2025 года: прямые утечки LAN-адресов идут на убыль, но новые векторы вроде mDNS и CGNAT создают устойчивые privacy-риски, которые требуют редизайна на уровне протокола.

Тестирование VPN-сервисов в 2025 году подтвердило очевидное: топовые блокируют 95-100% WebRTC-утечек. Бюджетные зачастую не блокируют ничего. Ноль. Вы платите $3 в месяц, думаете, что защищены, а ваш IP льётся через тот самый лаз для собаки.

Заплатка mDNS: пластырь на фонтан

В 2019 году, начиная с Chrome M74, Google стал подменять локальные IP на случайные mDNS-токены вроде a1b2c3d4-e5f6.local. Вместо 192.168.1.42 сайт видит бессмысленный UUID. Проблема решена?

Нет. Три проблемы.

Первая: mDNS-токен стабилен в рамках сессии. Одна и та же строка на весь сеанс. Это вектор трекинга. Имени нет, а отслеживать можно.

Вторая: в 2022 году всплыл баг в Chromium: локальный IP утекал через атрибут foundation в ICE-кандидатах. Prflxion-атака от Peer5 в 2023 году расширила эту брешь.

Третья и главная: mDNS прикрывает только host-кандидаты. Публичные IP, полученные через STUN, не защищены ничем. STUN-запрос уходит мимо VPN, вытаскивает настоящий IP, и mDNS тут бессилен. Пластырь закрывает царапину, а фонтан бьёт как ни в чём не бывало.

Что видно даже без IP

Допустим, все IP скрыты. STUN заблокирован. mDNS работает идеально. Следы всё равно остаются.

Сетевой fingerprint по типу NAT. Комбинация типов ICE-кандидатов это карта вашей сети. host и srflx означает обычный домашний NAT. Только relay означает симметричный NAT или корпоративный firewall. Только host означает прямой публичный IP. Этот fingerprint переживает сессии и очистку cookies. Подделать его, не сломав WebRTC целиком, почти нереально.

CGNAT как метка оператора. Адреса из диапазона 100.64.0.0/10 указывают на конкретного мобильного оператора и примерную зону внутри его сети. Сложите с MSS из TCP-отпечатка, который мы разбирали в статье о серверном фингерпринтинге, и получите идентификацию оператора, которую ни WebRTC, ни TCP не дают поодиночке.

STUN-тайминг как геолокация. Ответ STUN-сервера из Франкфурта за 3 мс говорит, что вы в Германии. За 150 мс, что в Австралии. Даже если IP скрыт через relay, время отклика палит вашу географию. Скрытая геолокация, которая работает без единого IP-адреса.

Ловушка отключения. Выключили WebRTC? Firefox: media.peerconnection.enabled = false. Поздравляю: вы теперь в крошечном меньшинстве тех, кто это делает. Ваш браузер стал на порядки уникальнее. Та же ловушка, что с блокировкой JavaScript или отключением cookies: щит превращается в маяк.

Тройное несовпадение. WebRTC показывает IP в стране А. DNS-резолвер в стране Б. HTTP-запрос приходит из страны В. Три разных ответа на вопрос, где вы, и анонимности конец. WHOX ловит именно этот каскад через check C07. Каждая утечка по отдельности мелочь. Вместе они складываются в приговор.

---

WHOX - Отличаем настоящие сигналы от сфабрикованных. Проверьте свой отпечаток на whox.com и узнайте какие сигналы утекают из вашего браузера и насколько вы уникальны.

FAQ

Мой VPN говорит, что защищает от WebRTC-утечек. Он врёт? Зависит от VPN. Топовые блокируют 95-100% WebRTC-утечек. Бюджетные зачастую не блокируют ничего. Расширения VPN для браузера текут, пока WebRTC не убит руками. Единственный способ узнать: проверить.

Как отключить WebRTC? Firefox: about:config, затем media.peerconnection.enabled выставить в false. Chrome: только через расширение вроде WebRTC Leak Prevent. Мобильный Chrome: никак. Помните про ловушку: отключение WebRTC само по себе fingerprint.

Tor Browser действительно закрывает проблему? Да. Tor это единственный браузер из протестированных в 2025 году, который стабильно блокирует все формы WebRTC-утечек на всех платформах. Расплата: скорость и совместимость.

Что проверяет WHOX? WHOX анализирует все поля fp.rtc.*: host, srflx, relay кандидаты, тип NAT, метаданные ICE. Тест A09 прицельно ищет WebRTC-утечки и сопоставляет их с 300+ другими сигналами.

---

Это краткий обзор WebRTC-утечек. Полный технический разбор с академическими источниками и механикой ICE/STUN/TURN ищите в WebRTC и DNS: утечки, которые не закрывает никто.

Читайте также

• WebRTC и DNS: полное исследование с академическими данными, механикой ICE, тестами на всех платформах
• Серверный фингерпринтинг: 4 слоя до JavaScript
• DNS-over-HTTPS: приватность, которой нет
• Что реально работает: гайд по защите