Утечка IP WebRTC: почему после смены прокси вас всё равно «рассекречивают»
Лао Чжоу, продающий на Amazon, потратил почти тысячу юаней на резидентный прокси, и в клиенте всё выглядело нормально. Пока однажды он не заглянул на сайт проверки IP и не обнаружил на странице сразу два IP: один американский, один китайский. Американский — купленный им прокси, китайский — его домашний широкополосный канал.
Тогда он не придал этому значения. Только когда третий магазин заморозили за «связку», он вспомнил ту странную страницу.
Это не единичный случай. Разбирая проблемы аккаунтов клиентов, я обнаружил, что в большинстве случаев «сменил прокси, а всё равно заблокировали» проблема не в качестве прокси, а в собственном «чёрном ходе» браузера — WebRTC. Эта статья объясняет всё: как он обходит прокси, что будет при утечке, как проверить себя и как закрыть лазейку.
WebRTC — это «пожарная лестница» браузера, которую прокси не контролирует
Представьте прокси как консьержа в подъезде, а WebRTC как пожарную лестницу — консьерж контролирует парадную дверь, но не контролирует потайную дверь на лестнице, ведущую прямо в вашу квартиру.
На техническом уровне эти два пути делают совершенно разную работу:
- Прокси берёт на себя «главную дорогу» веб-запросов, то есть трафик HTTP/HTTPS. Вы думаете, что «весь трафик идёт через прокси», но на самом деле — только часть веб-сёрфинга.
- WebRTC использует внутренний механизм реального времени браузера, с помощью протоколов STUN/ICE (на базе UDP) напрямую спрашивая внешний сервер: «какой у меня публичный адрес». Этот процесс происходит внутри ядра браузера, и прокси-инструмент его даже не видит, не говоря уже о блокировке.
Вот правда, стоящая за «двумя IP одновременно» у Лао Чжоу: веб-запросы шли через американский прокси, а WebRTC тихо выдавал домашний адрес.
Какие сценарии чаще всего приводят к проблеме? Функции реального времени — видеозвонки, голосовые соцсети, онлайн-коллаборация — главная зона риска; e-commerce и соцсети в обычном использовании не срабатывают, но молча зондируют в ключевые моменты вроде входа и оплаты — не убережёшься.
Как один утёкший IP тянет за собой целую пачку аккаунтов?
Случай Лао Чжоу — лучшая иллюстрация:
- Связка тем самым подтверждена. При входе в первый магазин платформа увидела его домашний IP через WebRTC; при входе во второй магазин — снова тот же домашний IP. Два «независимых» магазина были подключены к одной линии — слово «связка» так и записали в досье рисков.
- Затем — пакетная обработка. Как только связка установлена, когда страдает один аккаунт, страдают и другие магазины, рекламные кабинеты и платёжные счета того же владельца — упал один, упала вся пачка.
- Самое неприятное — это не отмывается. Утекает не только IP, но и реальное географическое положение и данные оператора. Попав в досье рисков, эта информация почти не стирается ни сменой окружения, ни сменой прокси.
Многие продавцы считают «смену прокси» панацеей, упуская именно это: прокси меняет «сетевую личность», но не меняет «реальный адрес», который браузер выдаёт сам.
Самопроверка за 2 минуты: ваш реальный IP «голый»?
Не нужно разбирать браузер или ставить программы — откройте любой сайт проверки IP (ipleak.net, BrowserScan подойдут) и за три шага всё станет ясно:
- Сначала проверьте «голое состояние». Откройте страницу проверки на домашней сети и запишите показанный IP — это ваша «реальная карта».
- Затем проверьте с включённым прокси. Включите прокси и обновите ту же страницу.
- Сравните колонку WebRTC. Если в ней появился IP вашей домашней сети — чёрный ход открыт; если показан IP прокси или пусто — защита работает.
Вот слепая зона, в которую попадает большинство: на страницах проверки часто несколько колонок сразу (IP, DNS, WebRTC), и многие смотрят только на самую заметную колонку «IP» — увидели, что стал американским, и успокоились, — а колонки DNS и WebRTC, где и спрятаны мины, никто не смотрит.
Как правильно закрыть этот чёрный ход?
Сначала — почему три «очевидных» способа не работают:
- Поставить блокирующее расширение: большинство расширений, блокирующих WebRTC, закрывают лишь часть путей запуска и пропускают в новых сценариях.
- Купить более дорогой прокси или VPN: прокси работает на сетевом уровне и не достаёт до ядра браузера — сколько ни плати, не поможет (это уже обсуждалось в статье Браузер с отпечатком vs VPN).
- Полностью отключить WebRTC: закрывает намертво, но видеозвонки и онлайн-встречи перестают работать — это как отказываться от еды, боясь подавиться.
Настоящее решение — обработка на уровне ядра браузера: браузер с отпечатком напрямую изменяет поведение API, связанных с WebRTC, чтобы веб-скрипты не могли получить ваш реальный адрес. Взять MasBrowser: при создании окружения в настройках отпечатка выберите для WebRTC значение «запрещено», и браузер больше не будет зондировать локальные сетевые интерфейсы через WebRTC. Полную настройку независимых окружений и изоляции отпечатка можно посмотреть на странице безопасного управления мультиаккаунтами MasBrowser.
После настройки вернитесь на страницу проверки. Убедитесь, что реальный IP больше не появляется в колонке WebRTC, — только тогда чёрный ход по-настоящему закрыт.
Часто задаваемые вопросы
Утечка WebRTC и утечка DNS — это одно и то же?
Нет. Утечка DNS происходит, когда прокси не полностью обрабатывает DNS-запросы и они уходят через местного оператора; утечка WebRTC — когда родная функция браузера обходит прокси и напрямую выдаёт IP. Обе раскрывают реальную сетевую среду, но пути разные, и страницы проверки показывают их раздельно.
С резидентным прокси WebRTC всё равно утекает?
Да. Утечка не зависит от типа прокси — пока функция WebRTC в браузере не обработана правильно, будь то резидентный или датацентровый прокси, он всё равно обойдёт туннель и выдаст реальный IP. Главное — закрыть WebRTC, а не покупать прокси дороже.
Если поставить WebRTC в «запрещено», повлияет ли это на обычное использование?
Практически нет. Подавляющее большинство веб-приложений (e-commerce, соцсети, работа) не использует WebRTC; страдают только видеозвонки, онлайн-встречи и P2P-передача — для таких сценариев просто создайте отдельное окружение без запрета WebRTC.
Если страница проверки вся зелёная — я абсолютно безопасен?
Значит, этот слой защиты на месте. Но безопасность мультиаккаунтов — это «комбинированный удар»: WebRTC лишь одно звено сетевого уровня — нужно сочетать с изоляцией отпечатка, привязкой прокси и согласованностью поведения. Один зелёный пункт не значит общую безопасность.
Заключение
Сменили прокси, а всё равно заблокировали — в девяти случаях из десяти дело не в прокси, а в незакрытой «пожарной лестнице» браузера: она обходит прокси и сообщает платформе ваш реальный адрес напрямую.
Хорошая новость: решение несложное. Обработайте WebRTC на уровне ядра браузера, после настройки проведите проверку. В бесплатной версии уже есть 2 слота окружений — скачайте MasBrowser, создайте окружение, поставьте WebRTC в «запрещено» и проверьте, не всплывает ли ваш реальный IP. Этот шаг стоит сделать на каждом аккаунте.
