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

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

WebRTC использует ICE/STUN для поиска маршрута к peer-to-peer-соединению. На практике это значит: браузер может опросить сетевые интерфейсы, собрать candidate-адреса и отдать наружу не только публичный адрес, но и локальную подсеть. Для антифрод-систем это удобный сигнал корреляции: браузерный отпечаток выглядит «чистым», а сетевой стек внезапно показывает несоответствие.

Разберем энтропию данного параметра: утечка обычно идёт через host candidates, srflx candidates и, реже, через mDNS-обход маскировки. Если в профиле активен прокси, а WebRTC всё равно видит прямой маршрут, детект на уровне сетевого стека становится тривиальным. Особенно плохо, когда браузер разрешает IPv6-канал, а пользователь маскирует только IPv4.

Рабочая защита строится не на «выключить всё», а на контроле поверхности: ограничить WebRTC на уровне браузерных политик, отключить ненужные UDP-маршруты, проверить, что STUN-запросы не уходят мимо туннеля, и сверить результат в BrowserLeaks или CreepJS. Если нужен WebRTC для звонков, оставляют только те сценарии, где трафик гарантированно идёт через доверенный интерфейс; иначе — изоляция профиля и жёсткий сетевой периметр.

Отдельно проверяйте, что маскировка не ломает сам WebRTC-сабстек: иногда «защита» убивает медиасоединения, но не убирает утечку сигналов. Практика простая: сначала дамп трафика, потом тест candidate-list, и только после этого считать профиль безопасным.