WebRTC через mDNS: как корпоративная сеть всё равно выдаёт лишнее

WebRTC через mDNS: как корпоративная сеть всё равно выдаёт лишнее

WebRTC давно пытается спрятать локальный IP за mDNS-именем, но браузерное окружение передает больше данных, чем кажется. В корпоративной среде это не отменяет утечек: сигнатура строится не только на адресе, но и на маршрутизации, DNS-поведении, таймингах и реакции прокси.

Анализируем энтропию параметров. Если в трафике виден .local-резолвинг, а рядом всплывают STUN/TURN-запросы, можно связать устройство с внутренним сегментом даже без прямого IP. Разбираем сигнатуру на уровне syscall: попытки открыть UDP-сокеты, смена интерфейсов, одинаковые ошибки резолва — всё это стабильно коррелирует с конкретным стеком и политиками сети.

Что проверять в логе и на периметре:
— есть ли исходящие запросы на mDNS и кто их инициирует;
— блокируются ли STUN-сессии или уходят наружу через обходной маршрут;
— совпадает ли время WebRTC-активности с всплесками DNS и ARP;
— не раскрывается ли внутренний адрес через fallback-механизмы браузера.

Скрытность — это не отсутствие следов, это шум, сливающийся с фоном. Если нужна реальная оценка риска, смотрите не на один IP, а на связку mDNS, UDP, DNS и таймингов: именно она показывает, где браузер анонимен только на бумаге.