WebRTC Leak Test

Проверьте, не раскрывает ли WebRTC ваш реальный IP адрес за VPN или прокси

КАК ЭТО РАБОТАЕТ

Процесс проверки утечки WebRTC

WebRTC API

Создаём peer-соединение

ICE КАНДИДАТЫ

Собираем ICE-кандидаты

СРАВНЕНИЕ IP

Сравниваем с IP VPN

ОТЧЁТ ОБ УТЕЧКЕ

Генерируем отчёт

WebRTC: семь лет на полу-починку утечки IP

В 2015 году исследователь выложил на TorrentFreak десять строк JavaScript, которые читали ваш настоящий публичный IP сквозь любой VPN. Подвох: код работал потому что браузер был спроектирован именно так. WebRTC, тот самый API под видеозвонками и голосовухой в Discord, изначально устроен раскрывать сетевую топологию пользователя. Скрыть её значило поломать видеозвонки. Через семь лет Chrome начал по умолчанию маскировать локальные IP случайными random.local. Та же утечка через srflx из 2015 года (настоящий публичный IP через STUN) до сих пор работает в дефолтном Firefox в 2026 году. Большинство расширений с надписью "WebRTC Leak Protection" реальную дыру не закрывают. Они прячут IP от JavaScript-читалки, но ICE-кандидат всё равно уходит по сети. Дальше: архитектура, что делают популярные фиксы, и что реально затыкает течь.

Анатомия утечки

Открой RTCPeerConnection в браузере. Подсунь любой STUN, например stun.l.google.com:19302. Слушай событие icecandidate. Печатай всё что приходит. Готово. Десять строк. Что приходит: каждый IP, к которому браузер считает что у него есть доступ. Host-кандидаты (локальные IP сети, 192.168.1.42 или 10.0.0.5). Server-reflexive (публичный IP, каким его видит Google STUN). Иногда relay-кандидаты (адреса TURN-серверов). Архитектурный принцип WebRTC: полнота важнее приватности. Раздать приложению все доступные сетевые пути и пусть само решает. Та же логика что у портье отеля, который выдаёт гостю всю связку мастер-ключей вместо одного от номера 204. Главная деталь: UDP-пакеты, которые собирают этих кандидатов, выходят через дефолтный маршрут ОС. Обычно это VPN-туннель. Не всегда. Конкретно Chrome исторически собирал кандидатов параллельно через все интерфейсы, а не только через дефолтный. Туннель отдаёт один набор, физический wifi другой, страница читает оба. Теперь страница знает и VPN-IP, и настоящий публичный. Mozilla закрыла это в 2017 году настройкой `media.peerconnection.ice.proxy_only`, которая до сих пор выключена по умолчанию. mDNS в Chrome с 2019 года прячет только локальные IP, к srflx-утечке не относится. Десять лет спустя srflx-канал по-прежнему открыт настежь если не выключить руками.

Почему "WebRTC leak protection" обычно не работает

Популярный совет с Reddit-тредов: поставь расширение "WebRTC Leak Prevent" или "WebRTC Control" или ещё какое-нибудь модное. Совет неправильный по специфическому поводу. Расширения умеют переопределить RTCPeerConnection и спрятать кандидатов от JavaScript, читающего события. Страница которая вызывает `pc.onicecandidate` получает пустоту. Выглядит как починено. Сборка ICE при этом всё равно происходит на сетевом уровне. UDP-пакеты по-прежнему уходят через настоящий интерфейс. Пассивный наблюдатель в сети видит STUN-трафик и может его сопоставить. Провайдер. Файрвол офиса. Любой с tcpdump в той же локалке. IP никуда не делся, просто ушёл туда, куда JavaScript-блокер не дотянется. Звукоизоляция двери в комнате с окнами. То же самое с большинством VPN-расширений для браузера. Они переопределяют API на JavaScript-уровне. Сетевой слой под ним остаётся нетронутым. mDNS-хеширование в Chrome с 2019 года это уже посерьёзнее. Локальные IP (host-кандидаты) меняются на случайные хостнеймы вида c0fb3b9e-3d05-4a14-b2c2-7e51e4d1f5d1.local. Страница не прочтёт 192.168.1.42 напрямую. К srflx-кандидатам это не относится. Ваш публичный IP, обнаруженный через STUN, по-прежнему уходит, по-прежнему логируется. Быстрый тест работает ли ваш фикс: запустите любой WebRTC leak detector с видимым mDNS. Если видите srflx-кандидаты с настоящим публичным IP (не VPN-овским), ничего не починилось. Страница просто перестала рекламировать своё чтение.

Что реально затыкает течь

Есть ровно три способа остановить утечку WebRTC. Ни один из них не расширение. Первое: режим только-TURN. Заставить браузер использовать только relay-кандидатов, никаких host или srflx. Firefox: about:config, `media.peerconnection.ice.proxy_only = true`. Chrome флага не даёт. Реальная починка требует либо политики Chrome Enterprise, либо стороннего инструмента вроде режима "I'm an advanced user" в uBlock Origin с включённым `media.peerconnection.ice.relay_only`. Сайд-эффект: видеозвонки теперь идут через TURN-сервер, добавляется от 30 до 80 мс задержки и удваивается потребляемый трафик. Кому-то стоит того, кому-то нет. Дальше слой сети. Дроп всего UDP-трафика на не-VPN интерфейсах через firewall-правила. Linux: nftables на output, drop UDP если src не tun-устройство. Windows: встроенный killswitch у WireGuard это делает при правильной конфигурации. macOS: pf, конфиг руками. Когда UDP не может выйти за туннель, STUN тоже не может, и srflx возвращает только VPN-IP. Третий вариант: просто отключить WebRTC. Firefox: about:config, `media.peerconnection.enabled = false`. Chrome: флага нет, нужна та же enterprise-политика. Сайд-эффект: Google Meet перестаёт работать. Discord-голосовуха в браузере перестаёт работать. Slack-звонки тоже. Zoom в браузере тоже. Это правильный ответ для журналиста и неправильный для всех, кто реально пользуется видеозвонками. Сканер WebRTC-утечек в WHOX опрашивает STUN-серверы по нескольким типам ICE-кандидатов и показывает, какой именно тип утёк, а не просто да/нет. Удобно когда проверяешь правильно ли настроен режим только-TURN или покрывают ли firewall-правила UDP.

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Как отключить WebRTC?

В Firefox: перейдите в about:config и установите media.peerconnection.enabled в false. В Chrome: установите расширение для блокировки WebRTC. Большинство VPN-расширений для браузера также включают защиту от утечек WebRTC.

Что такое ICE-кандидат?

ICE (Interactive Connectivity Establishment) кандидаты — это потенциальные сетевые пути для WebRTC-соединений. Они включают ваш локальный IP, публичный IP, обнаруженный через STUN, и relay-адреса от TURN-серверов.

Опасна ли утечка WebRTC?

Да, утечка WebRTC может раскрыть ваш реальный IP адрес сайтам даже при использовании VPN. Это сводит на нет цель использования VPN для приватности и может раскрыть ваше настоящее местоположение.

Все наши тесты

Запускайте весь набор WHOX из одного блока: проверки утечек, fingerprint-пробы, сетевую диагностику, репутацию IP и тесты приватности.