Прокси может охватывать HTTP-трафик, тогда как WebRTC обменивается адресами-кандидатами через STUN/ICE по UDP. В статье объясняется, когда могут раскрываться локальные и частные адреса и как согласовать сетевой выход со средой браузера.
Прокси уже настроен, а страница проверки IP показывает ожидаемый регион и провайдера. Сетевая идентичность выглядит корректно. Но если открыть тест на утечки, раздел WebRTC становится красным и показывает адрес вашего реального интернет-соединения.
Не спешите сразу менять прокси. В большинстве случаев проблема не в его качестве, а в трафике, который он не контролирует.
Прокси обрабатывает HTTP, а WebRTC использует другой путь
Прокси работает на сетевом уровне. Независимо от того, реализован он как расширение браузера или как системный туннель, он обрабатывает HTTP/HTTPS-запросы и направляет этот трафик через выход прокси.
WebRTC работает иначе. Это встроенная в браузер возможность связи в реальном времени. Чтобы аудио-/видеозвонки и P2P-передача нашли подходящий маршрут, браузер может активно отправлять STUN-запросы внешним серверам — по сути спрашивая: «Какой адрес вы видите у меня?» — а затем оформлять ответы как ICE-кандидаты и передавать их веб-странице. Эти запросы используют UDP, то есть канал, независимый от HTTP-туннеля.
В результате возникает расхождение: запросы веб-страницы уходят через прокси, а браузер одновременно может сообщить локальный адрес. Предположение, что настройка прокси автоматически делает всю сетевую идентичность “чистой”, — самая распространённая отправная точка этой проблемы.
Раскрыться может не только публичный IP
ICE-кандидаты обычно содержат два типа адресов. Первый — публичный адрес, то есть выход вашего реального интернет-провайдера. Второй — локальный адрес, например частный адрес, начинающийся с 192.168; иногда также встречается адрес виртуального сетевого адаптера.
Сам по себе адрес частной сети мало что доказывает: он есть почти у каждого компьютера. Но он может быть достаточно стабильным, чтобы повторяющиеся совпадения адресов-кандидатов у нескольких аккаунтов стали для платформы дополнительным сигналом для их связи с одним устройством. Публичный адрес более прямой: он указывает на реального провайдера и примерный географический район. Точность зависит от платформы, но принцип понятен: чем реальнее адрес, тем проще установить связь.
Когда сайт действительно может прочитать адрес?
Не каждый сайт пытается это делать. Для обмена адресами страница должна активно создать объект RTCPeerConnection, который обычным контентным страницам, как правило, не нужен.
Чаще всего это встречается у сервисов, которым нужна связь в реальном времени, например видеоконференций, онлайн-поддержки и некоторых страниц прямых трансляций; у сайтов, сильно зависящих от рекламы или противодействия мошенничеству; а также у платформ с развитыми системами управления рисками. Считывание происходит за пределами видимого интерфейса, а после сбора данных вы обычно не получаете уведомления о том, как они используются дальше.
Есть и ситуация, не связанная с самим сайтом. В короткий промежуток, когда прокси переподключается или переключается на другой узел, STUN-запрос браузера может уйти через локальную сеть. Окно очень короткое, но его достаточно, чтобы зафиксировать одно наблюдение.
Три распространённых сценария сбоя
Прокси в виде расширений браузера обычно перехватывают только HTTP/HTTPS-запросы. UDP остаётся вне их зоны действия, и включение в интерфейсе «глобального» режима этого не меняет.
Системный глобальный прокси выглядит более полным, поскольку охватывает трафик всего устройства. Однако сбор адресов-кандидатов может напрямую привязываться к локальному сетевому интерфейсу и обходить системную таблицу маршрутизации, оставляя брешь в туннеле на этом этапе.
Третья проблема не только техническая, но и связана с развитием систем контроля. Системы управления рисками всё чаще используют WebRTC-адреса как один из сигналов для связывания аккаунтов. Данные, которые раньше не измерялись или игнорировались, теперь могут учитываться при оценке.
Цель — согласованный сетевой выход, а не просто отключение одного переключателя
Есть несколько общих подходов. Если рабочему процессу совсем не нужна связь в реальном времени, проще всего отключить WebRTC. Цена этого — недоступность таких функций, как видеозвонки и онлайн-поддержка.
Если эти функции нужно сохранить, распространённый подход — сделать адрес, возвращаемый на уровне WebRTC, согласованным с выходом прокси. Более надёжный вариант — также направлять STUN-запросы через прокси-канал, чтобы интерфейс не раскрывал локальный адрес. Если нужны P2P или видеозвонки, через прокси должен проходить весь UDP-трафик, а не только HTTP-уровень.
Распространённая ошибка — считать, что одного отключения WebRTC достаточно для “чистой” среды. Важна взаимная согласованность сетевого выхода, DNS-разрешения, принадлежности IP и ASN, часового пояса и языка, а также характеристик устройства. Любое несоответствие может оставить аномальный сигнал; WebRTC — лишь один из элементов, который особенно легко упустить.
Проверка проста. Выполните тест после смены узла и ещё раз перед обычным использованием среды: откройте тест на утечки и проверьте, показывает ли раздел WebRTC выход прокси, локальный адрес или реальный публичный адрес. Обычная проверка IP этого не показывает.
Изоляция сред на уровне движка браузера позволяет задать отдельную политику WebRTC-адресов для каждой среды и связать её с соответствующим сетевым выходом. PurpleMark предоставляет именно такие возможности. Если несколько сред используют один выход или их адресные политики не согласованы, ценность изоляции значительно снижается.
Это только техническое объяснение. Используйте соответствующие инструменты с соблюдением правил платформ и местного законодательства.
