WebRTC и DNS: почему одного прокси мало

Прокси скрывает реальный IP адрес для HTTP/HTTPS-трафика браузера. Но у браузера есть и другие “способы” сообщить свой реальный IP. Два из них стоит проверять отдельно: WebRTC и DNS.

WebRTC и DNS — это нормальные части браузера и сети. Проблема начинается, когда сетевые проверки показывают не согласоввность: сайт открыт через прокси, но WebRTC или DNS leak-тест указывает на другой маршрут.

WebRTC: зачем он вообще нужен

WebRTC используется для P-to-P аудио- и видеозвонков, демонстрации экрана и передачи данных между браузерами. Чтобы найти рабочий путь между двумя сторонами, WebRTC использует ICE. MDN описывает ICE-кандидаты как варианты сетевого соединения, через которые клиенты может общаться напрямую или через промежуточный сервер: WebRTC connectivity. Сам ICE описан в RFC 8445.

В этом месте появляется риск де-маскировки. RFC 8828 прямо говорит, что WebRTC может раскрывать веб-приложению больше информации о локальной сети, чем обычный HTTP-запрос. В документе перечислены понятные случаи: дополнительные публичные IP при нескольких сетевых интерфейсах, приватные адреса за NAT и обход классического application proxy через STUN, если прямой доступ в интернет разрешён.

Проще: если обычная страница видит только IP прокси, WebRTC при плохой настройке может показать настоящий IP адрес.

Как выглядит WebRTC-утечка

Сценарий такой: HTTP-трафик идёт через прокси, но WebRTC собирает ICE-кандидаты по другому маршруту.

В исследовании One Leak Will Sink A Ship автор проверял браузеры и VPN-сервисы и показывал, что WebRTC API мог делать IP-адреса доступными сайту через JavaScript даже при включённом VPN. Исследование старое, поэтому его нельзя читать как описание всех современных браузеров один в один. Но оно хорошо объясняет сам класс проблемы: WebRTC живёт не совсем в том же слое, что обычный запрос страницы.

Почему не всегда стоит просто выключать WebRTC

Выключить WebRTC полностью — самый грубый вариант. Иногда он подходит, но у него есть цена: ломаются звонки, screen sharing, data channels и любые проверки, где сервис ожидает, что WebRTC API работает.

Даже Chrome не сводит вопрос к “включить/выключить”. В Chrome есть политика webRTCIPHandlingPolicy, которая управляет тем, как WebRTC-трафик маршрутизируется и сколько локальной адресной информации раскрывается сайтам. В документации Chrome Extensions перечислены режимы, включая disable_non_proxied_udp: chrome.privacy API. У Chrome Enterprise есть отдельная политика для WebRTC IP handling: Chrome Enterprise policy.

Вывод простой: нормальная цель — не сломать WebRTC, а сделать так, чтобы он не показывал маршрут, который противоречит профилю.

DNS: где может появиться несостыковка

DNS переводит доменное имя в IP-адрес. Cloudflare объясняет это коротко: DNS переводит читаемые домены вроде example.com в IP-адреса, с которыми работают машины: What is DNS?.

DNS-утечка — это ситуация, когда основной трафик идёт через VPN или прокси, а DNS-запросы уходят другим путём. Mozilla объясняет это на примере VPN: DNS-запросы могут выйти вне защищённого туннеля, если VPN настроен неправильно или не маршрутизирует DNS через свою сеть: What is a DNS Leak?.

С прокси важна та же логика: где именно резолвится домен. В документации curl хорошо видно различие между локальным и удалённым DNS. socks5:// означает SOCKS5 с локальным разрешением имени, а socks5h:// — SOCKS5 с разрешением имени на стороне прокси: everything curl: Proxies.

Нужно быть точными: обычный сайт не всегда напрямую видит ваш DNS-резолвер. Поэтому не стоит писать, что “любой сайт сразу узнает DNS”. Правильнее так: DNS-утечка показывает, что сетевой маршрут настроен не полностью. Это можно поймать на DNS leak-тестах, в собственной инфраструктуре или в системах, которые контролируют свои домены и сетевые логи.

Что мы проверяем в 0detect

Для нас WebRTC и DNS — часть единого сетевого профиля. Если профиль работает через прокси, остальные сетевые параметры должны быть согласованы с ним и не создавать конфликтов.

В нашей документации по созданию профиля сеть вынесена в отдельный блок “Соединение”: к профилю можно прикрепить прокси, выбрать прокси из списка и настроить DNS. Для DNS есть режим “Настоящий”: если профиль работает через прокси, DNS берётся в зависимости от прокси; если прокси нет, используется ваш адрес; при необходимости DNS можно указать вручную: Создание профиля.

Там же в общих настройках профиля есть язык, часовой пояс и геолокация. По документации эти параметры по умолчанию подбираются с учётом внешнего IP. Это не про WebRTC напрямую, но про ту же идею: IP, DNS, таймзона, язык и геолокация должны складываться в одну историю.

Для автоматизации порядок тоже важен. В Local API прокси создаётся отдельно, привязывается к профилю через POST /profile/set/proxy, и только после этого профиль запускается: Работа с proxy. Это снижает риск ситуации, когда скрипт уже открыл браузер, а сетевой профиль ещё не соответствует профилю.

Коротко

WebRTC может раскрывать больше сетевой информации, чем обычный HTTP-запрос. DNS может уходить не тем маршрутом, если резолвинг настроен локально или мимо прокси.
Хороший профиль — это не “прокси поверх браузера”. Это браузер, у которого сетевые настройки, отпечаток и география не противоречат друг другу.