Тест утечки WebRTC: не выдаёт ли браузер ваш реальный IP?

Что на самом деле означает утечка WebRTC

WebRTC — это часть браузера, благодаря которой видеозвонки работают без плагина. Чтобы два человека могли говорить напрямую, каждый браузер должен выяснить, как до него можно добраться, — а для этого собрать все адреса, по которым он может быть доступен: тот, который выдал ему роутер, тот, который провайдер выдал роутеру, и всё, что между ними. Эти адреса называются ICE-кандидатами, и браузер собирает их ещё до того, как кто-либо согласился на звонок.

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

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

Как эта страница проверяет утечку и что куда передаётся

Тест основан на сравнении, и обе его половины видны выше. Первая половина — адрес, с которого был запрос к этой странице: его записал наш сервер, когда ваш браузер запросил этот URL, и его видит любой обычный сайт. Вторая половина — то, что ваш браузер сам сообщает, когда начинает собирать ICE-кандидаты.

Чтобы собрать маршрутизируемый кандидат, браузер должен спросить у STUN-сервера: «с какого адреса пришёл мой пакет?», потому что внутри вашей сети этого не знает никто. Без этого вопроса теста на утечку WebRTC не существует: страница, которая обещает проверить утечки, ни к чему не обращаясь, не проверяет ничего. Эта страница обращается к публичному STUN-серверу Cloudflare напрямую из вашего браузера. Вопрос и ответ не проходят через нас, и результат нигде не сохраняется: нажмите кнопку — и изменится только текст на вашем экране.

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

Деталь, на которой ошибается большинство тестов на утечку

Chrome, Edge и Safari больше не показывают адрес вашей локальной сети в виде обычного 192.168.x.x. Они заменяют его случайным именем, оканчивающимся на .local, которое по mDNS разрешают только устройства в вашей собственной сети. Это настоящее улучшение приватности, и оно ломает любой тест, который считает, что «адрес локальной сети не виден» означает «ничего не утекает». Отсутствие адреса доказывает, что браузер его скрывает, но ничего не говорит о маршрутизируемом адресе — том, который действительно вас идентифицирует. Мы показываем эти два адреса отдельно, поэтому скрытый адрес локальной сети отображается как скрытый, а не тихо засчитывается как успешная проверка.

Как читать результат

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

Другой маршрутизируемый адрес. Это и есть утечка. Прокси закрывает ваши запросы к страницам, но не кандидатов WebRTC. Самая частая причина — прокси, настроенный внутри браузера, или расширение, которое его задаёт: и то и другое перехватывает HTTP, и ни то ни другое не перехватывает UDP, который использует WebRTC.

Маршрутизируемого адреса нет вовсе. Читать нечего — и это самый чистый результат из возможных. Обычно это значит, что WebRTC отключён, расширение блокирует запрос к STUN или ваша сеть его отбрасывает. Некоторые корпоративные сети дают такой результат случайно.

Виден приватный адрес. Сам по себе он вас не выдаёт — 10.0.0.4 описывает несколько сотен миллионов машин. Но он сообщает сайту, как устроена ваша сеть, и это ещё одно значение в отпечатке.

Как закрыть утечку

В браузере нет настройки, которая направляет WebRTC через HTTP-прокси, так что «настроить прокси как следует» — не то решение, которого от неё ждут. Что работает:

• Отключите WebRTC. В Firefox задайте media.peerconnection.enabled значение false в about:config. В Chrome такого переключателя нет, там нужно расширение. Видеозвонки в этом браузере перестанут работать — такова цена.
• Направьте через туннель всё устройство, а не браузер. Туннель на уровне системы или прокси, заданный в ОС или на роутере, несёт UDP-трафик WebRTC вместе со всем остальным, поэтому собранные кандидаты — это адреса туннеля.
• Возьмите браузер, сделанный для этого. Антидетект-браузеры намеренно привязывают WebRTC к тому же адресу, что и остальная сессия; за это вы в основном и платите.
• Не полагайтесь на расширение, которое только прячет результат. Некоторые расширения подменяют показываемого кандидата, вместо того чтобы не дать его собрать, а расхождение между подменённым значением и остальным отпечатком само по себе заметно.

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