Утечка WebRTC: какие данные о вашей сети она может раскрыть
Опубликовано: Время чтения: ≈ 5 мин
Краткий ответ
WebRTC позволяет общаться и обмениваться данными прямо в браузере. При подготовке соединения браузер собирает возможные адреса для связи. Страница может получить среди них IP вашего интернет-провайдера, даже если обычная проверка показывает прокси. Если вы рассчитывали скрыть этот IP, его раскрытие называют утечкой.
Но не каждый незнакомый адрес в отчете означает проблему. Сначала выясните, относится ли он к вашему подключению, локальной сети или серверу-посреднику.
Главное
- Прокси для загрузки страниц не обязательно охватывает соединения WebRTC.
- Имя с окончанием .local может заменять локальный IP. Публичные адреса в отчете все равно нужно проверить.
- Отключение этой технологии может нарушить работу браузерных звонков. После изменения настроек проверьте и связь.
Зачем WebRTC собирает сетевые адреса?
Чтобы установить связь, браузеру нужны варианты подключения к другому участнику. Механизм ICE собирает такие варианты – кандидаты. Среди них могут быть адрес устройства, публичный IP, полученный через STUN, и адрес сервера TURN для передачи трафика через посредника. Браузер проверяет связь между парами кандидатов по правилам ICE, чтобы установить соединение.
Прокси для веб-страниц может не охватывать этот процесс. RFC 8828 описывает ситуацию, когда клиент настроен на обычный прокси, но прямой доступ в интернет остается разрешенным. Тогда STUN может обнаружить исходный публичный IP.
С VPN тоже нужно учитывать настройки. Например, исключение для браузера может отправлять его трафик вне туннеля. Доступные пути зависят также от правил браузера и маршрутов операционной системы.
Какие данные могут появиться в результате проверки?
Адрес вроде 192.168.1.20 относится к локальной сети. Одинаковое значение может встречаться в разных домах и офисах, поэтому по нему нельзя определить публичный IP вашего подключения. Если браузер использует mDNS, вместо числа вы можете увидеть имя с окончанием .local.
Публичный IP провайдера позволяет сайту связать обычное подключение с сеансом, который идет через прокси. Именно эту запись стоит проверить, если вы хотели скрыть исходное подключение.
Адрес TURN-сервера принадлежит посреднику. Он может отличаться от IP, который показывает обычная проверка, и это само по себе не означает утечку. Кроме того, наличие кандидата в списке еще не говорит, что соединение использовало этот путь.
Несколько адресов в отчете еще не означают несколько утечек. Сначала разберите их по типам. Если список пуст, страница не получила кандидатов в этом запуске; причину по одному такому результату установить нельзя.

Как проверить WebRTC и что делать при неожиданном публичном IP?
Начните с профиля, в котором используете прокси или VPN. Проверка в другом профиле может дать другой результат.
- Запишите IP обычного веб-запроса и подозрительный публичный адрес из WebRTC-результата. Если инструмент показывает тип кандидата, сохраните и его.
- Сравните найденный адрес с ожидаемым IP прокси или VPN и, если он вам известен, с IP прямого подключения. Совпадение с последним означает, что браузер раскрыл исходный публичный адрес.
- Проверьте, действует ли прокси в этом профиле и нет ли исключения для браузера в VPN-клиенте. Затем посмотрите настройки защиты от утечек и ограничения WebRTC.
- Меняйте по одному параметру и повторяйте проверку. Так будет понятно, какая настройка повлияла на результат.
Условный пример: прокси показывает один IP, WebRTC – другой
Представим, что обычная проверка показывает настроенный прокси, а подробный WebRTC-отчет содержит три записи:
- 192.168.1.20 – адрес в локальной сети.
- Другой публичный IP – совпадает с IP подключения без прокси.
- Кандидат с типом relay – адрес TURN-сервера.
Во второй строке браузер раскрыл исходное подключение, хотя веб-запрос прошел через прокси. Первая и третья строки такого вывода не подтверждают. Это условный пример чтения отчета, а не результат тестирования конкретного сервиса.
Где выполнить проверку?
В MangoProxy есть тест утечек DNS, WebRTC и IPv6. Откройте его в нужном профиле и запустите проверку. Блок WebRTC показывает итоговый статус, а не подробный список кандидатов. Сохраните результат перед изменением настроек – он пригодится для сравнения. У DNS и IPv6 отдельные блоки, их результаты нужно читать независимо.
Ниже – пример проверки. Числовой IP на скриншоте скрыт.

Словарь
WebRTC – технологии для передачи аудио, видео и данных между участниками через браузер.
IP-адрес – числовой адрес сетевого интерфейса.
Прокси – сервер-посредник, через который клиент отправляет настроенный для него трафик.
VPN – виртуальная частная сеть; VPN-клиент направляет трафик через туннель согласно настройкам.
DNS – система поиска IP-адресов по доменным именам.
IPv6 – версия интернет-протокола со 128-битными адресами.
ICE и ICE-кандидат – механизм поиска и проверки вариантов соединения и отдельный вариант адреса для связи.
STUN – протокол, с помощью которого клиент может узнать свой адрес, видимый снаружи сети.
TURN – протокол передачи данных через сервер-посредник.
mDNS – система локальных имен; браузер может использовать такое имя вместо числового адреса кандидата.
Итог
Сравнивайте результат с тем подключением, которое собирались использовать. Если браузер раскрыл IP провайдера, проверьте, какой трафик обходит прокси или VPN. Сохраненный отчет поможет оценить результат после настройки.
Часто задаваемые вопросы
Здесь мы ответили на самые часто задаваемые вопросы. Все равно не можешь найти ответа?
Может ли WebRTC показать точный домашний адрес?
Публичный IP позволяет приблизительно определить провайдера и регион. Он не подтверждает конкретный дом или почтовый адрес. Частный IP описывает адрес внутри локальной сети.
Нужен ли доступ к камере или микрофону для проверки?
Не обязательно. Браузер может готовить соединение только для передачи данных, без звука и видео. Какие сведения получит страница, зависит от браузера, его настроек и правил доступа.
Если тест не нашел реальный IP, что это говорит о других приложениях?
По нему нельзя оценить их подключение: проверен только один профиль браузера. Например, отдельное приложение для видеовстреч может использовать собственные настройки сети.
Поможет ли смена прокси устранить утечку?
Если трафик вообще не доходит до прокси, замена сервера не изменит его маршрут. Сначала исправьте настройки клиента и повторите проверку. После этого будет понятнее, нужен ли другой сервис.