WebRTC сливает реальный IP даже при прокси: где течет и как закрыть утечку

WebRTC сливает реальный IP даже при прокси: где течет и как закрыть утечку

WebRTC — это не «магия видеозвонков», а набор API поверх ICE/STUN/TURN. При сборе кандидатов браузер часто публикует локальные и публичные адреса в SDP, а дальше их можно вытащить через JS без доступа к сетевому стеку. Разберем энтропию данного параметра: утечка возникает не только через публичный IP, но и через mDNS-обходы, которые в ряде сценариев деградируют до реального адреса.

Типовые точки утечки:
— RTCPeerConnection и createDataChannel: кандидат-лист формируется до того, как вы успели «спрятать» сеть.
— STUN-запросы: внешний сервер видит исходящий адрес, если политика маршрутизации не принудительная.
— browser fingerprint: сайты сверяют WebRTC-адрес с IP из HTTP/TLS и ловят рассинхрон.

Что реально снижает риск:
— Отключать WebRTC на уровне профиля или политики браузера, а не только через расширение. Расширение может скрыть UI, но не изменить логику генерации ICE-кандидатов.
— Использовать изоляцию профиля и отдельный сетевой контур: прокси должен быть не «в окне», а на уровне всего трафика.
— Проверять не один сайт, а несколько тестов: разные движки по-разному показывают локальные, VPN и host-кандидаты.

Под капотом Chromium API важно смотреть не на «галочку в настройках», а на результат: если SDP содержит host/srflx, утечка уже случилась. Значит, нужен контроль политики WebRTC, блок STUN и проверка через дамп кандидатов.

Если нужен стабильный результат, проверяйте не обещания софта, а SDP, ICE-кандидаты и сетевой лог: там сразу видно, спрятан IP или только замаскирован интерфейс.