Даже с активным VPN механизм ICE/STUN в WebRTC может раскрыть ваш реальный публичный IP. Как работает утечка, как её проверить и как устранить.
Утечка WebRTC происходит, когда функция браузера для связи в реальном времени раскрывает ваш истинный IP-адрес — включая реальный публичный IP — даже при активном VPN. Чтобы остановить это, нужно либо отключить WebRTC, либо ограничить его использованием только сетевого интерфейса VPN, либо запустить VPN, который явно блокирует утечки WebRTC. Ниже мы подробно объясняем, как именно происходит утечка, как её протестировать и как безопаснее всего её устранить, не ломая видеозвонки.
Что такое WebRTC и почему браузеры его поставляют
WebRTC (Web Real-Time Communication) — это технология браузера, которая позволяет веб-страницам обмениваться аудио, видео и произвольными данными напрямую между двумя устройствами — по принципу «точка-точка» (peer-to-peer) — без плагинов. Она лежит в основе видеоконференций прямо в браузере, голосовых вызовов, демонстрации экрана и передачи файлов на таких сайтах, как Google Meet, Discord, а также в бесчисленных виджетах чатов поддержки.
Поскольку WebRTC соединяет два узла напрямую, а не пропускает всё через центральный сервер, каждый узел должен узнать, как другого можно достичь в сети. Именно этот процесс обнаружения и является корнем утечки. WebRTC — это не вредоносное ПО и не ошибка: он делает ровно то, для чего был создан. Проблема в том, что тот же механизм, что находит лучший сетевой путь для вашего видеозвонка, может также передать ваш реальный IP-адрес любому скрипту на странице.
Процесс ICE: STUN, TURN и сбор кандидатов
Чтобы установить прямое соединение, WebRTC использует фреймворк под названием ICE (Interactive Connectivity Establishment), стандартизированный в RFC 8445. ICE собирает все возможные способы, которыми два узла могут достичь друг друга, и ранжирует их по формуле приоритета, определённой в этом RFC — сначала хост-кандидаты, затем серверно-рефлексивные, затем релейные, — поэтому браузер всегда сначала пробует самый прямой (и самый раскрывающий) путь, прежде чем откатиться к релею. Каждый из них называется кандидатом.
Существует три основных типа кандидатов:
- Хост-кандидаты (host) — локальные сетевые адреса вашего устройства (например, LAN-адреса
192.168.x.xили10.x.x.x, а иногда и адреса IPv6). - Серверно-рефлексивные кандидаты (server-reflexive) — ваш публичный IP, каким он виден снаружи, обнаруженный через запрос к серверу STUN. Сервер STUN (Session Traversal Utilities for NAT) просто отвечает: «вот публичный IP и порт, с которых я вижу ваше подключение». Именно этот кандидат способен раскрыть ваш реальный IP.
- Релейные кандидаты (relay) — запасной вариант, который пропускает медиапоток через сервер TURN, когда прямое соединение невозможно. Серверы TURN ретранслируют трафик, поэтому не раскрывают новый IP, но расходуют пропускную способность и используются лишь в крайнем случае.
Опасность в том, что ICE собирает кандидатов активно и незаметно. Веб-страница может создать соединение, никогда никому фактически не звонить и всё равно считать собранных браузером кандидатов — включая публичный IP, обнаруженный через STUN.
Почему VPN не всегда вас спасает
Вот часть, которая удивляет большинство пользователей VPN. Когда вы подключаете VPN, ваш обычный веб-трафик туннелируется через интерфейс VPN, поэтому whatismyip показывает адрес VPN. Но STUN-запрос WebRTC — это отдельный UDP-поток. В зависимости от правил маршрутизации вашей операционной системы, настроек раздельного туннелирования VPN и поведения браузера при привязке к интерфейсу этот STUN-запрос может пройти через ваш реальный сетевой интерфейс, а не через туннель. Тогда сервер STUN сообщает ваш реальный публичный IP, и страница его считывает — полностью обходя VPN.
Иными словами, VPN защищает ваш HTTP-трафик, пока WebRTC тихо сливает IP, который вы пытались скрыть. Если хотите проверить, действительно ли ваш VPN маскирует адрес, запустите инструменты BrowserInsight проверка VPN/прокси и IP-аналитика, чтобы увидеть, что в действительности наблюдает внешний мир.
Маскировка через mDNS .local и её пределы
Современные браузеры на Chromium (Chrome, Edge) и Firefox добавили меру против раскрытия локальных IP: вместо того чтобы выдавать необработанный хост-кандидат 192.168.x.x, они заменяют его рандомизированным mDNS-именем хоста вида a1b2c3d4-....local. Этот адрес .local ничего не значит для удалённого скрипта, поэтому топология вашей локальной сети остаётся приватной, а соединение по-прежнему работает в пределах локальной сети.
Стандарт, который регулирует эту область, — RFC 8828 («WebRTC IP Address Handling Requirements»). Сам приём с .local он не предписывает: вместо этого он задаёт четыре режима обработки IP и то, сколько сведений о вашей сети каждый из них вправе раскрыть. Режим 1 перечисляет все адреса, режим 2 использует маршрут по умолчанию вместе со связанными локальными адресами, режим 3 — только маршрут по умолчанию, режим 4 принудительно направляет трафик через прокси. Случайное mDNS-имя — это реализация, к которой браузеры пришли, чтобы удовлетворить строгий край этой шкалы для хост-кандидатов: браузер публикует случайное имя в локальном сегменте сети и отдаёт наружу именно имя, а не адрес, так что сам LAN-адрес не покидает вашу машину.
Это настоящее улучшение, но у него есть два важных ограничения:
- Оно скрывает только хост-кандидаты (локальные). Серверно-рефлексивный кандидат по определению и есть публичный адрес — это то, откуда, по данным STUN-сервера в открытом интернете, пришёл ваш пакет, и подменить его локальным именем попросту нечем. Ваш реальный публичный IP mDNS не скрывает, а это и есть та утечка, которая важнее всего для пользователей VPN.
- Оно зависит от поддержки браузером и платформой. Старые браузеры, некоторые встроенные веб-вью и определённые конфигурации всё ещё могут раскрывать необработанные локальные IP.
Таким образом, mDNS снижает отслеживаемость по вашему LAN-адресу, но не является защитой от утечки публичного IP.
Пользователям VPN в RFC 8828 помогает другое — режим 3. «Только маршрут по умолчанию» означает, что WebRTC вправе задействовать лишь тот интерфейс, которым операционная система и так пользуется для обычного трафика, а при поднятом VPN этот интерфейс — туннель. Тогда STUN-запрос уходит через туннель, и серверно-рефлексивный кандидат сообщает адрес VPN, а не ваш. Именно это и делают под капотом браузерные настройки из следующего раздела.
Как выглядит утечка в коде
Чтобы запустить сбор кандидатов, специальный инструмент не нужен. Любая страница может сделать это с помощью стандартного интерфейса RTCPeerConnection, определённого в спецификации W3C WebRTC, — достаточно нескольких строк JavaScript. Приведённый ниже фрагмент создаёт одноранговое соединение, направляет его на публичный сервер STUN и выводит каждого кандидата, которого обнаруживает браузер:
// Показать IP-кандидатов, которых собирает WebRTC
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
// Заставить браузер начать сбор ICE-кандидатов
pc.createDataChannel('leak-test');
pc.onicecandidate = (event) => {
if (!event.candidate) return; // сбор завершён
const candidate = event.candidate.candidate;
// Строки ICE-кандидата содержат IP в поле 5
const ipMatch = candidate.match(
/([0-9]{1,3}(\.[0-9]{1,3}){3})|([a-f0-9]{1,4}(:[a-f0-9]{0,4}){2,7})/i
);
if (ipMatch) {
console.log('Candidate type:', event.candidate.type);
console.log('Exposed address:', ipMatch[0]);
}
};
pc.createOffer().then((offer) => pc.setLocalDescription(offer));
Если event.candidate.type равен srflx (server-reflexive), а выведенный адрес — это ваш реальный публичный IP, а не IP вашего VPN, значит, у вас есть утечка WebRTC.
Как протестировать утечку WebRTC
Тестирование занимает около минуты:
- Подключите VPN и убедитесь, что он активен.
- Запомните публичный IP, который, по заявлению VPN, он вам выдаёт, — его покажет страница IP-аналитики BrowserInsight.
- Запустите проверку VPN/прокси BrowserInsight. Она выполняет тот самый сбор кандидатов прямо в вашем браузере и показывает публичный IP из WebRTC рядом с тем IP, с которого реально приходят ваши HTTP-запросы, помечая расхождение как утечку WebRTC. (Если хотите увидеть всё «сырьём», вставьте приведённый выше код в консоль браузера.)
- Сравните адреса, которые раскрывает WebRTC, с IP вашего VPN.
Если WebRTC показывает IP, совпадающий с вашим VPN, вы защищены. Если он показывает другой публичный IP — ваш домашний или адрес провайдера — это и есть утечка. Утёкший IP имеет значение для трекера лишь в том случае, если он действительно указывает на вас, а IP-геолокация менее точна, чем многие полагают — хотя обычно её достаточно, чтобы раскрыть ваш город и провайдера. Для перекрёстной проверки того, что раскрывает ваше соединение помимо WebRTC, это хорошо сочетается с тестом на утечку DNS, поскольку утечки DNS и WebRTC часто имеют общую первопричину: трафик, ускользающий из туннеля.
Меры защиты для каждого браузера
Единого переключателя, который чинит WebRTC повсюду, не существует, потому что каждый браузер обрабатывает его по-своему. В таблице ниже сведены практические варианты.
| Браузер / платформа | Как смягчить | Компромисс |
|---|---|---|
| Chrome / Edge (десктоп) | Отдельной настройки в интерфейсе нет: политика обработки IP доступна только через расширение. Собственное расширение Google, WebRTC Network Limiter, переводит её в вариант «только публичный интерфейс по умолчанию» — режим 3 из RFC 8828, — и кандидаты собираются только на туннеле | Расширение может сломать некоторые видеоприложения |
| Firefox | Откройте about:config, установите media.peerconnection.enabled в false, чтобы полностью отключить WebRTC | Полностью ломает видео- и голосовые вызовы через WebRTC |
| Safari (macOS/iOS) | В стабильных сборках выключателя для пользователя нет. На iOS это вообще не вопрос выбора браузера: все браузеры там работают на WebKit, так что смена браузера ничего не меняет — нужен системный VPN, блокирующий утечки WebRTC | Ограниченный контроль |
| Brave | Встроенная настройка: измените политику обработки IP в WebRTC на «Disable non-proxied UDP» в настройках конфиденциальности — самый строгий вариант, соответствующий режиму 4 из RFC 8828 | Может затронуть приложения «точка-точка» |
| Мобильные (Android/iOS) | Используйте браузер с управлением WebRTC (Brave, Firefox) или VPN-приложение, блокирующее WebRTC на сетевом уровне | VPN на уровне приложения — самое надёжное мобильное решение |
Самое чистое решение для большинства пользователей VPN — вовсе не флаг браузера, а выбор VPN, чьи десктопные и мобильные приложения явно заявляют о защите от утечек WebRTC и обеспечивают её на сетевом уровне ОС, чтобы STUN-запрос никогда не смог покинуть туннель.
Отключение WebRTC против его ограничения
Полное отключение WebRTC (через media.peerconnection.enabled в Firefox) гарантирует отсутствие утечки, но ломает все видеозвонки, голосовые чаты и демонстрации экрана в браузере. Для большинства людей это слишком радикально.
Лучший баланс — ограничить WebRTC, чтобы он использовал только интерфейс вашего VPN, что и делает расширение для предотвращения утечек или VPN с поддержкой WebRTC. Вы сохраняете работающие видеозвонки, закрывая при этом утечку публичного IP. Полное отключение оставьте для специального усиленного профиля браузера, в котором вы никогда не совершаете звонки.
Часто задаваемые вопросы
Останавливает ли VPN утечки WebRTC автоматически?
Не всегда. VPN туннелирует ваш обычный веб-трафик, но STUN-запрос WebRTC может пойти отдельным путём через ваш реальный сетевой интерфейс в зависимости от маршрутизации и настроек раздельного туннелирования. Многие качественные VPN добавляют явную защиту от утечек WebRTC, но лучше проверить, чем полагаться на предположение.
Сломает ли отключение WebRTC сайты?
Оно ломает функции, которые используют WebRTC, — видеоконференции в браузере, голосовые вызовы, демонстрацию экрана и некоторые передачи файлов «точка-точка». Обычный просмотр, стриминг и большинство сайтов это не затрагивает. Если вы полагаетесь на видеозвонки, ограничьте WebRTC, а не отключайте его.
Делает ли меня безопасным маскировка через mDNS .local?
Она скрывает ваш локальный LAN-IP, что хорошо для снижения отслеживаемости, но не скрывает публичный IP, который обнаруживает STUN. Утечка публичного IP — та самая, что важна для пользователей VPN, — mDNS не затрагивает.
Как узнать, действительно ли мой VPN скрывает мой IP?
Сравните IP, который заявляет ваш VPN, с тем, что в действительности видят сервисы. Инструменты BrowserInsight проверка VPN/прокси и IP-аналитика показывают адрес и сетевые данные, которые наблюдает внешний мир, что позволяет легко заметить скрытую утечку.
Заключение
WebRTC — это полезная технология, которую браузеры справедливо поставляют по умолчанию, но её процесс сбора кандидатов может раскрыть ваш реальный публичный IP даже за VPN. Решение не в том, чтобы бояться WebRTC, а в том, чтобы понять механизм ICE/STUN, протестировать собственную конфигурацию и применить правильный уровень защиты: ограничить WebRTC туннелем для повседневного использования или полностью отключить его в усиленном профиле. Сначала протестируйте, затем выбирайте компромисс, который подходит к тому, как вы пользуетесь сетью.
Рекомендуем прочитать:
