Утечка WebRTC: как её найти и закрыть навсегда

Ситуация, из-за которой люди перестают доверять VPN: индикатор зелёный, сервис рапортует о подключении к Нидерландам, а сайт здоровается по имени вашего города. Причина почти всегда одна и та же, и лежит она не в VPN, а в браузере. Проверить это можно прямо сейчас на нашей странице «Мой IP» — там видно оба адреса сразу. А ниже — что с этим делать.

Откуда берётся второй адрес

WebRTC придумали, чтобы браузеры звонили друг другу напрямую, без сервера-посредника. Для этого браузеру нужно узнать все адреса, по которым до вас можно достучаться, — список так и называется, «кандидаты соединения». Он собирает их у операционной системы и отдаёт странице через обычный JavaScript.

Важная деталь: никакого разрешения на это не спрашивается. Доступ к камере и микрофону требует подтверждения, а сбор кандидатов — нет, потому что формально это не приватные данные. Поэтому утечка webrtc происходит молча и мгновенно: скрипт на любой открытой вкладке получает ваш настоящий webrtc ip за доли секунды.

Утечка — не взлом и не уязвимость. Это штатная работа технологии, которая просто не знает, что вы хотели спрятаться.

Главная причина, и она не в браузере

Чаще всего течёт не у тех, кто «неправильно настроил Chrome», а у тех, кто пользуется VPN-расширением вместо VPN. Расширение — это прокси для вкладок: оно заворачивает HTTP-запросы браузера и больше ничего. WebRTC работает по UDP напрямую и мимо прокси не идёт, адрес берёт у системы, и наружу уходит настоящий.

Системный VPN такой дыры не оставляет по устройству: когда весь трафик устройства идёт через туннельный интерфейс, WebRTC получает его адрес — другого у него просто нет. Разница между этими двумя вещами разобрана в статье «VPN-расширение для браузера: почему это не VPN», и утечка WebRTC — самое наглядное её проявление.

Отсюда практический вывод, который экономит вечер: если вы сидите на расширении, все настройки ниже — лечение симптома. Работать они будут, но дыра останется одна из трёх.

Что считать утечкой, а что нет

Прежде чем чинить, стоит понять, что именно вы увидели. Проверка показывает адреса трёх видов, и пугаться нужно только одного.

• Локальный адрес — 192.168.x.x, 10.x.x.x или строка вида a1b2c3d4-….local. Это адрес внутри вашей квартиры. Он одинаковый у миллионов роутеров и сам по себе никого не выдаёт. Современные браузеры маскируют его специально.
• Адрес VPN-сервера — совпадает с тем, что показано вверху страницы проверки. Так и должно быть.
• Публичный адрес, отличный от VPN-овского — вот это утечка. Если он совпадает с адресом, который вы видите при выключенном VPN, дыра подтверждена.

Chrome, Edge и Яндекс Браузер

Все трое на одном движке, поэтому лечатся одинаково. Плохая новость: встроенного переключателя нет — флаг #disable-webrtc убрали из chrome://flags несколько лет назад, и советы из старых статей ведут в пустую страницу. Остаются два рабочих пути.

Путь первый — расширение. Самое известное называется WebRTC Control; есть аналоги вроде WebRTC Leak Prevent. Ставится из магазина расширений, включается одной кнопкой. Именно поэтому запрос webrtc control ищут чаще, чем саму утечку: люди сразу идут за инструментом. Тот же webrtc расширение одинаково работает и в webrtc яндекс-браузере — магазин там общий с Chrome.

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

Путь второй — политика. Более чистый и без сторонних дополнений. У Chromium есть параметр WebRtcIPHandlingPolicy — та самая политика обработки ip webrtc, — и у него четыре значения:

1. default — отдаёт всё, поведение по умолчанию;
2. default_public_and_private_interfaces — публичный и локальный;
3. default_public_interface_only — только публичный, локальный скрыт;
4. disable_non_proxied_udp — то, что нужно: запрещает UDP в обход прокси, то есть WebRTC вообще не может взять адрес мимо туннеля.

На Windows это ключ реестра в HKLM\Software\Policies\Google\Chrome, на macOS — запись в defaults, на Linux — JSON-файл в /etc/opt/chrome/policy/managed/. Звучит громоздко, но настраивается один раз и переживает обновления браузера, в отличие от расширений.

Firefox

Здесь всё честнее: настройка встроенная. Открываете about:config, соглашаетесь с предупреждением и правите один-два параметра.

media.peerconnection.enabled в false отключает WebRTC целиком. Вариант радикальный: звонки в браузере перестанут работать вовсе. Мягче — оставить технологию включённой, но запретить ей лишнее: media.peerconnection.ice.default_address_only в true оставляет один адрес вместо списка, а media.peerconnection.ice.no_host в true убирает локальные адреса из кандидатов. В связке они закрывают утечку, не ломая видеосвязь.

Safari и телефоны

Safari с одиннадцатой версии не отдаёт локальные адреса без разрешения, и отдельная настройка там обычно не нужна. Полное отключение живёт в меню «Разработка» → «Экспериментальные функции», но трогать его стоит только при подтверждённой проверкой утечке.

С мобильными сложнее, и об этом мало пишут. В мобильном Chrome на Android расширений нет вовсе — значит первый путь отпадает, а политику применить негде. В Safari на iPhone ситуация та же. Остаётся единственное решение, и оно же самое надёжное: системный VPN, который заворачивает весь трафик устройства. Браузеру тогда просто неоткуда взять другой адрес.

Проверить, что дыра закрылась

1. Включите VPN и запомните адрес, который он показывает.
2. Откройте «Мой IP» и посмотрите блок «Утечки» — проверка запрашивает у браузера кандидатов ровно так, как это сделал бы любой сайт.
3. Сравните: публичный адрес в блоке утечек должен совпадать с адресом VPN.
4. Повторите в режиме инкогнито — расширения там по умолчанию выключены, и это покажет, держится ли защита без них.
5. Перезапустите браузер и проверьте ещё раз: часть настроек сбрасывается обновлением.

Более широкий тест на утечку и полная проверка анонимности по восьми сервисам — в статье «Как проверить VPN: 8 сервисов для полного теста».

Две соседние дыры, которые обычно забывают

Утечка DNS. Адрес подменён, WebRTC молчит, а устройство продолжает спрашивать «какой адрес у этого сайта» у резолвера провайдера — мимо туннеля. Адрес чужой, а список посещённых доменов ваш. Лечится тем же системным VPN, который забирает себе и DNS-запросы.

Kill switch. Вопрос kill switch vpn что это задают отдельно от утечек, хотя это про то же самое. Соединение с сервером на секунду упало, туннель поднимается заново — и в этот промежуток трафик идёт напрямую. Kill switch блокирует сеть, пока туннель не восстановится: неприятно, но честно. Без него самая аккуратная настройка WebRTC ничего не стоит, потому что момент обрыва её обходит.

Почему у нас этой проблемы нет по устройству

VIPASS — не расширение и не прокси: ключ поднимает системный туннель, через который идёт весь трафик устройства целиком. WebRTC в такой схеме физически не может взять другой адрес — у системы его просто нет. Туда же уходят и DNS-запросы, так что вторая дыра закрывается тем же движением.

Плюс у каждого клиента собственный сервер, а не общий на сотни человек. В контексте анонимности это отдельная вещь: даже безупречно закрытый WebRTC не спасает, если ваш адрес делят с тем, кто в это же время рассылает спам, — капчу покажут вам обоим. Про границы того, что VPN вообще скрывает, у нас есть честный разбор «VPN и анонимность: что скрывает VPN, а что нет».

Попробовать можно через @vipass_robot в Telegram — бесплатно, за две минуты, карта не нужна. Проверить результат — на той же странице «Мой IP».

Частые вопросы