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

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

WebRTC — это не «дырка» в браузере, а набор API поверх ICE, STUN и DTLS, который пытается построить P2P-канал мимо лишних посредников. Именно на этапе кандидат-адресов локальная и внешняя связность попадает в JS-видимость, если стек не ограничен политикой или расширением. Разберем энтропию данного параметра.

Типичный детект строится на сравнении:
— public IP из HTTP-запроса;
— candidate addresses из RTCPeerConnection;
— mDNS-имен и локальных интерфейсов;
— таймингов и последовательности ICE-событий.
Если в candidates всплывает адрес из другой подсети или IPv6-слой не согласован с прокси-маршрутом, антифрод видит несостыковку быстрее, чем по Canvas.

Практическая защита всегда состоит из трех уровней: отключение нежелательного WebRTC на уровне браузерной политики, фильтрация локальных candidates через расширение или pref, и проверка, что UDP-трафик не уходит в обход туннеля. Под капотом Chromium API важнее не сам факт запрета, а то, остается ли в JS-окружении след от ICE-обмена и доступ к enumerateDevices/peer connection state.

Отдельно проверяйте split-tunneling: если DNS и HTTP идут через прокси, а STUN — напрямую, утечка почти гарантирована. Анализ структуры TLS Client Hello тут не спасает: проблема возникает раньше, на уровне сетевого стека и поведения WebRTC-сессии.

Если нужен стабильный профиль, тестируйте связку «браузер + сетевой маршрут + антидетект-политика» как единое целое, а не по одному переключателю.