Проверка на утечку WebRTC: как предотвратить утечки IP

Работающий прокси не гарантирует защиту всех подключений браузера. Тест на утечку WebRTC помогает проверить маршрутизацию, предотвратить неожиданное раскрытие IP и сохранить ваше присутствие в сети защищённым и стабильным. Ниже — полный гайд о том, как это сделать.

Что такое WebRTC

WebRTC (Web Real-Time Communication) — открытый стандарт, который позволяет браузерам и приложениям обмениваться аудио, видео и данными в реальном времени без плагинов. Обычно он использует UDP для связи с низкой задержкой, но поддерживает также TCP и подключения через ретрансляторы.

Для установки соединения WebRTC собирает ICE-кандидаты (Interactive Connectivity Establishment): возможные сетевые адреса подключения, содержащие адрес, порт и транспортный протокол. Именно эти кандидаты служат источником всех возможных утечек. 

Почему прокси «протекают» через WebRTC

Утечка WebRTC возникает, когда при определении параметров подключения браузер раскрывает адрес, который ваша схема маршрутизации должна скрывать. Тест на утечку WebRTC помогает это выявить.

1. Веб-страница запускает сбор WebRTC-кандидатов.

2. Браузер обращается к STUN-серверу, чтобы узнать свой публичный адрес.

3. Если это соединение идёт в обход прокси, STUN видит адрес вашего интернет-провайдера.

4. Браузер может передать этот адрес JavaScript-коду страницы через ICE-кандидат.

Что важно помнить:

• Настройки прокси в браузере не обязательно распространяются на трафик WebRTC.

• Правильно настроенный VPN с полным туннелированием должен пропускать и этот трафик; WebRTC сам по себе не обходит шифрование VPN.

Чем опасны утечки WebRTC

Раскрытый публичный IP может выдать вашего сетевого провайдера и примерное местоположение, но не имя и не точный адрес. Кроме того, он может привести к следующему:

• Сопоставление разных браузерных сессий между собой.

• Ограничения по местоположению.

• Дополнительная верификация или проверка аккаунта.

Это возможные последствия, а не гарантированные. Тем не менее лучше соблюдать осторожность и регулярно проводить тесты на утечку WebRTC.

Чем отличаются утечки DNS и WebRTC

Утечки DNS связаны с тем, куда уходят запросы на разрешение доменных имён; утечки WebRTC — с тем, какие адреса раскрываются при определении параметров подключения. Один тест не заменяет другой.

DNS-тест обычно выявляет рекурсивные резолверы, а не публичный IP вашего устройства. Неожиданный резолвер стоит проверить, но одна лишь его страна не доказывает утечку.

Как проверить утечки WebRTC

По сути, тест на утечку WebRTC проверяет, появляется ли ваш настоящий IP среди ICE-кандидатов, видимых в браузере. Для этого подойдут специальные сервисы: BrowserLeaks, IPLeak или официальный инструмент WebRTC — Trickle ICE на GitHub.

1. Узнайте свои IPv4 и IPv6 без прокси/VPN

• Закройте рабочие сессии с важными данными, прежде чем отключать защиту.

• Откройте IPLeak.

• Запишите свой прямой публичный IPv4 и IPv6, если он есть.

• Не показывайте эти исходные адреса посторонним.

Сообщение «No IPv6 detected» означает лишь, что тест не установил IPv6-соединение, но не то, что IPv6 не может появиться позже.

2. Включите прокси/VPN и проверьте IP ещё раз

Подключите VPN или настройте прокси CyberYozh App в нужном профиле браузера или клиенте.

• Откройте новую вкладку для теста.

• Убедитесь, что публичный IP сменился на ожидаемый выходной адрес.

• Проверьте IPv4 и IPv6 по отдельности.

Смена IP при просмотре сайтов подтверждает, что маршрут соединения изменился, но утечки WebRTC всё равно могут остаться.

3. Откройте BrowserLeaks, IPLeak или Trickle ICE от WebRTC

Выберите онлайн-тест на утечку WebRTC:

• BrowserLeaks: изучите поле «Your WebRTC IP» и журнал SDP.

• IPLeak: используйте его комбинированный тест на утечки DNS и WebRTC.

• Trickle ICE: пример из проекта WebRTC; нажмите «Gather candidates» и изучите столбцы с адресами и типами. Это диагностический пример, а не полноценная проверка приватности.

4. Проверьте, нет ли в результатах вашего физического IP

Сравните результаты теста на утечку WebRTC с исходными адресами:

• Виден прямой публичный IP провайдера: значит, есть утечка IP, и причину нужно найти.

• Виден ожидаемый выходной адрес прокси/VPN: маршрутизация защищена.

• 192.168.x.x или 10.x.x.x: данные частной сети, а не ваш публичный адрес.

• Имя хоста .local: маскировка локального адреса, но не доказательство защиты публичного IP.

Если кандидатов нет или появилась ошибка, результат неубедителен. Переподключитесь и повторите проверку в другом инструменте. Если ни один из них не показывает утечек, всё в порядке. О том, как предотвратить утечки, читайте дальше.

Как предотвратить утечки WebRTC

Отключайте WebRTC, если он не нужен, а если звонки и приложения реального времени должны работать, настройте принудительную защищённую маршрутизацию. Блокировка UDP в обход прокси помогает, но не заменяет тест на утечку WebRTC, который показывает реальную картину.

В обычных браузерах

Воспользуйтесь подходящим гайдом по настройке браузера, затем примените нужную настройку:

• Firefox для ПК: about:config → media.peerconnection.enabled → false. Это отключает WebRTC.

• Chrome: используйте поддерживаемое расширение для приватности с опцией disable_non_proxied_udp.

• Brave: найдите в настройках пункт «WebRTC IP Handling Policy» и выберите «Disable Non-Proxied UDP».

• Microsoft Edge: используйте совместимое расширение для защиты WebRTC или управляемую политику; затем повторите тест.

• Safari: используйте принудительную маршрутизацию через VPN на уровне устройства; не полагайтесь на устаревшие инструкции с экспериментальным меню.

• Opera: включите блокировку UDP в обход прокси, если она доступна, или используйте поддерживаемое совместимое расширение.

В антидетект-браузерах

Следуйте инструкциям для антидетект-браузеров.

Назначьте прокси профилю, затем проверьте его настройки WebRTC. Если WebRTC не нужен, выберите режим «отключено»; в остальных случаях используйте опцию защищённой маршрутизации от разработчика браузера. 

Режимы вроде «Altered» в разных продуктах работают по-разному: подмена отображаемых кандидатов сама по себе не гарантирует, что сетевой трафик защищён. 

После настройки протестируйте каждый профиль.

В прокси-клиентах

Следуйте инструкциям для прокси-клиентов. Затем:

1. Импортируйте учётные данные CyberYozh. 

2. Включите режим TUN/полной маршрутизации, если он поддерживается.

3. Убедитесь, что вышестоящий прокси поддерживает UDP.

4. Направьте DNS по нужному маршруту

5. Отключите нежелательный прямой доступ при сбое. 

Режим системного прокси сам по себе не равноценен туннелю для всего устройства. После настройки ещё раз проверьте реальную конфигурацию браузера на утечки WebRTC.

Настройки системного файрвола

Обратитесь к соответствующему гайду по настройкам ОС.

Включите kill switch для VPN в настройках Wi-Fi или добавьте правила для исходящего трафика, которые разрешают защищаемым приложениям выходить в сеть только через туннель или прокси-клиент. Охватите и IPv4, и IPv6. Так будет заблокирован весь прямой трафик в обход прокси, а риск утечки WebRTC снизится. 

Рекомендации по работе с учётом утечек WebRTC

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

• Повторяйте проверку после обновлений браузера, изменений в клиенте, смены сети и переподключений: успешный тест подтверждает только конкретную конфигурацию, а не все возможные состояния в будущем.

• Проверяйте DNS и IPv6 отдельно: отключение WebRTC не исправит маршрутизацию резолвера и не помешает обычным соединениям идти в обход защищённого сетевого маршрута.

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

• Сохраните нужную функциональность: после введения ограничений протестируйте звонки и демонстрацию экрана, затем задокументируйте рабочую конфигурацию, не сохраняя пароли от прокси и не публикуя исходные адреса.