Что такое утечка WebRTC
WebRTC — встроенная в браузер технология связи в реальном времени: видеоконференции, голосовые звонки, P2P-передача файлов и другие сценарии. Чтобы установить прямое соединение, браузер узнаёт свой внешний адрес через STUN-сервер. Такая проверка обычно идёт по UDP, а обычные HTTP / SOCKS-прокси UDP не обязательно перехватывают.
Если STUN-запрос обходит прокси и уходит напрямую из локальной сети, веб-скрипт может получить ваш настоящий публичный IP. Для этого обычно не нужен доступ к камере или микрофону и не появляется дополнительного запроса подтверждения, поэтому WebRTC и используют, чтобы проверить, действительно ли прокси охватывает трафик реального времени.
Как это определяет наш инструмент
Страница пробует WebRTC-запросы к нескольким STUN-серверам, собирает полученные публичные адреса и сравнивает их с выходным IP по HTTP. Если возвращённый адрес совпадает с текущим выходным IP, UDP, скорее всего, идёт через прокси; если приходит адрес вашего локального оператора, это повод разобраться.
- Проверяем, идёт ли UDP через выход прокси
- Определяем, течёт ли каждая из версий, IPv4 и IPv6, независимо
- Смотрим, не попадают ли разные STUN-цели под разные правила маршрутизации
Роль STUN и UDP
UDP — протокол передачи без установления соединения, который обычно используют для голоса, видео, игр и связи в реальном времени. Задача STUN проста: вы отправляете серверу UDP-пакет, а он сообщает, с какого исходного IP этот пакет пришёл. WebRTC опирается на этот результат при согласовании соединения, поэтому адрес, который увидел STUN, — главное доказательство при оценке утечки.
Как читать результаты
Утечек не найденоПубличный IP, который вернул WebRTC, совпадает с текущим выходом вашего прокси (для IPv6 — та же подсеть /64). Если публичный IP не вернулся вовсе, тест просто не получил ответа; это не доказательство безопасности.
Подозрение на утечкуWebRTC вернул другой публичный IP, а его расположение, оператор или ASN указывают на вашу настоящую локальную сеть.
Обычное разделение трафикаНесколько STUN-серверов вернули разные выходы прокси, но они соответствуют настроенной вами маршрутизации и правилам.
Что делать, если найдена утечка
- Переключите прокси-клиент в режим TUN, чтобы UDP от WebRTC тоже шёл через выход прокси.
- Chrome / Edge: задайте корпоративную политику <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>; Firefox: включите <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> в <code>about:config</code>. Не отключайте WebRTC полностью: браузер без WebRTC сам по себе выделяется среди остальных.
- Brave: выберите для политики обработки IP в WebRTC значение «Disable non-proxied UDP».
- Если нужны конференции или голосовые звонки, сначала настройте правила маршрутизации UDP / STUN в прокси-клиенте.
Несколько выходных IP — не обязательно утечка
Если вы настроили разделение трафика, разные STUN-серверы могут идти через разные узлы — например, STUN от Google через выход в США, а STUN от Cloudflare через выход в Гонконге. Это не обязательно опасно: главное — совпадает ли картина с вашими правилами. По-настоящему стоит насторожиться, когда все WebRTC-адреса указывают на ваше физическое местоположение или вашего локального провайдера.
Утечки DNS не менее важны
Утечка WebRTC раскрывает «ваш настоящий IP», а утечка DNS — «какие домены вы запрашивали». Если DNS-запросы не идут через прокси, ваш локальный оператор или вышестоящий резолвер по-прежнему видит, на какие сайты вы заходили.
Проверка утечки DNS на этой странице использует настоящий зонд: CleanIP.io держит по одному авторитетному NS в Юте, США (ns1) и в Лос-Анджелесе, США (ns2) для зоны dp.cleanip.io. При каждой проверке разрешается 8 независимых поддоменов <uuid>.dp.cleanip.io; эти запросы проходят через системный stub-резолвер -> провайдер / VPN / публичный рекурсивный резолвер и в итоге попадают на наш авторитетный NS, который записывает IP обратившегося резолвера и (если есть) EDNS Client Subnet, а затем возвращает вам для сравнения.
Смотрите на два сигнала: ① подсеть ECS — если рекурсивный резолвер передал подсеть вашего клиента (так часто делает Google 8.8.8.8), эта подсеть однозначно выдаёт клиента; ② страна резолвера — трансграничный anycast у публичных рекурсивных резолверов (1.1.1.1 / 8.8.8.8) — это нормально; важно другое: когда вы считаете, что VPN включён, совпадает ли расположение резолвера со страной вашего HTTP-выхода.
Почему режимы прокси и TUN дают разные результаты
HTTP / SOCKS-прокси обычно обрабатывают только TCP, поэтому UDP, который нужен STUN, может не отправиться, и страница покажет «утечки нет». Это не значит, что UDP надёжно идёт через прокси — это значит лишь, что UDP до STUN-сервера не дошёл. Режим TUN перехватывает и TCP, и UDP на виртуальном сетевом адаптере, поэтому точнее отражает реальный выходной путь UDP.
РежимSTUN по UDPЧто означает результат
HTTP / SOCKS-проксиМожет не отправиться«Утечки нет» может означать лишь то, что UDP заблокирован
TUN / виртуальный адаптерОтправляется по-настоящемуЛучше подходит для проверки выхода UDP и правил маршрутизации
Рекомендуем повторить проверку в том сетевом режиме, которым вы действительно пользуетесь: если обычно работаете через TUN, проверяйте через TUN; если полагаетесь на прокси в браузере, убедитесь также, что заблокированный UDP не принимается за безопасный результат. Оценивая утечку WebRTC, смотрите на ASN, расположение и на то, соответствует ли вернувшийся IP вашей схеме разделения трафика.