WebRTC может выдать реальный IP даже при активном прокси — если не закрыть STUN-канал

WebRTC может выдать реальный IP даже при активном прокси — если не закрыть STUN-канал

WebRTC — это не «дыра», а отдельный медиастек Chromium: ICE, STUN, TURN, RTP. Проблема в том, что для установления P2P-сессии браузер собирает кандидаты интерфейсов и может отдать:
— публичный адрес от NAT;
— приватный адрес LAN;
— IPv6, если он доступен;
— mDNS-имя вместо IP, если повезло с маскировкой.

Разберем энтропию данного параметра: антифрод смотрит не только на факт утечки, но и на согласованность отпечатка. Если в HTTP виден один регион, а в WebRTC — другой ASN или домашний провайдер, это уже детект на уровне сетевого стека. Плюс сопоставляются timing-корреляции: задержка STUN, порядок candidate gathering, наличие srflx и relay-кандидатов.

Практика защиты сводится к трём слоям:
— отключить WebRTC там, где он не нужен;
— принудительно ограничить IP-handling policy на прокси-only режим;
— проверить, что браузер не резолвит локальные адреса через JS-инъекцию и не светит их в enumerateDevices/RTCPeerConnection. Спуфинг через инъекцию JS-кода без контроля медиастека бесполезен: браузер всё равно может выдать сырой candidate из нативного слоя.

Проверять нужно не по обещаниям профиля, а через Pixelscan, CreepJS и локальный дамп candidate-событий. Если в логе есть host/srflx без relay, защита не работает. Всегда тестируйте связку «браузер + прокси + WebRTC» как единый контур: утечка IP обычно живёт не в интерфейсе, а под капотом Chromium API.