Тема

Популярные инструменты

Проверка утечки WebRTC

WebRTC может передать сайту адреса, которые ваш браузер иначе не отправил бы, — в том числе тот, что скрыт за вашим VPN. Эта проверка опрашивает три STUN-сервера Cloudflare и Google, показывает каждый полученный адрес и что он собой представляет, а затем сравнивает их с адресом, который сайт уже видит. Если что-то проверить не удаётся, она так и говорит, а не показывает зелёную галочку.

Выполняется в вашем браузере через STUN-серверы Cloudflare и Google · ничего не сохраняется · типы кандидатов по RFC 8445

Запустите проверку один раз с выключенным VPN и один раз с включённым. Разница и есть ответ.

Ваш браузер спрашивает три STUN-сервера Cloudflare и Google, какой адрес они видят. Ни один адрес, найденный WebRTC, не отправляется нам.

Что сайт видит и такIPv4IPv6Определяем ваше подключение…
Все адреса, которые выдал WebRTC

  1. Здесь появится каждый адрес, который выдаст WebRTC, — по строке на каждый, по мере ответов STUN-серверов.

Ни один адрес, найденный WebRTC, не отправляется нам. Ваш браузер сам опрашивает STUN-серверы, как при любом видеозвонке. Чтобы показать, что видит сайт, страница запрашивает ваши адреса и их сети у ipify.org и у нашего собственного сервера, как это делает Проверка утечки DNS.

Что такое утечка IP через WebRTC?

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

Этот сбор называется сбором ICE-кандидатов и описан в RFC 8445. Браузер перечисляет адреса ваших собственных сетевых интерфейсов, затем спрашивает STUN-сервер, с какого адреса он видит ваш запрос, и добавляет и этот адрес. Любая страница в интернете может запустить этот процесс несколькими строками JavaScript и читать каждого кандидата по мере поступления, без запроса разрешения: так задумано, ведь звонок должен работать и без него.

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

Что может запустить любая страницаодин сбор, шаг за шагом

ВАШЕ УСТРОЙСТВОИНТЕРНЕТВаш роутер (NAT)Скрипт страницыВаш браузерSTUN-серверstun.cloudflare.comnew RTCPeerConnection()без запроса разрешенияперечисляет все сетевые интерфейсы192.168.1.20 → 8b7f4e2a-….localс какого адреса я к вам прихожу?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400адрес, который он увиделкаждого кандидата, по мере поступленияonicecandidateВАШЕ УСТРОЙСТВОИНТЕРНЕТСкрипт страницыВаш браузерSTUN-серверnew RTCPeerConnection()без запроса разрешенияперечисляет все сетевые интерфейсы192.168.1.20 → 8b7f4e2a-….localс какого адреса я к вам прихожу?192.168.1.20203.0.113.7203.0.113.7:54400адрес, который он увиделкаждого кандидата, по мере поступленияonicecandidateВаш роутер (NAT)

Весь скрипт

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

Что он вывел

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

Что означает каждая строка

  • hostНа этом устройстве8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localЗамаскирован браузером
  • srflxУвидел STUN-сервер203.0.113.7Маршрутизируемый в интернете
Один сбор на домашнем подключении, с адресами для документации. Частный адрес никогда не покидает браузер в исходном виде; STUN-сервер видит публичную сторону роутера, а не устройство, и оба ответа попадают к тому скрипту, который их запросил.
Результат проверки утечки WebRTC: каждый ICE-кандидат с типом, видом адреса и вердиктомРезультат проверки утечки WebRTC: каждый ICE-кандидат с типом, видом адреса и вердиктомВердиктУтечка, утечки нет или — честно — проверить не удалось, с указанием причины.Каждый адресС типом кандидата, потому что кандидат типа host означает не то же самое, что кандидат типа server-reflexive.Что это за адресЧастный, NAT операторского уровня, туннель или маршрутизируемый. Утечкой может быть только маршрутизируемый адрес.СерверыКаждый STUN-сервер на своей строке. Сервер, который промолчал, — это проверка, которая не состоялась.Что видит сайтАдреса, которые ваш браузер отправляет и так: именно с ними сравниваются адреса WebRTC.
Пример запуска: что ответил каждый STUN-сервер, все адреса, которые раскрыл WebRTC, что это за адреса и видит ли их сайт и так. Выберите номер, чтобы узнать, что показывает каждая часть.

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

Запустите проверку выше. Она собирает кандидатов от трёх STUN-серверов, определяет, что представляет собой каждый адрес, и сравнивает маршрутизируемые адреса с адресом, который сайт уже видит.

Возможны три результата, а не два. Утечки нет означает, что каждый маршрутизируемый адрес, выданный WebRTC, у сайта уже есть. Утечка означает, что хотя бы одного из них у сайта нет — или что адрес на вашем собственном устройстве был передан напрямую. Проверить не удалось означает, что WebRTC выключен, заблокирован или ни один STUN-сервер не ответил; именно этот результат большинство инструментов молча превращают в успешный.

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

Три результата, а не двачто означает каждый

  1. Утечки нет

    Каждый маршрутизируемый адрес, выданный WebRTC, у сайта уже есть.

    WebRTC выдал

    • 198.51.100.23Увидел STUN-серверСайты его уже видят
    • 8b7f4e2a-….localНа этом устройствеЗамаскирован браузером

    Сайт видит

    198.51.100.23
  2. Утечка

    Хотя бы одного адреса у сайта ещё нет, или адрес на вашем собственном устройстве передан напрямую.

    WebRTC выдал

    • 198.51.100.23Увидел STUN-серверСайты его уже видят
    • 2001:db8:4a1f:7c00::1cНа этом устройствеСайты его не видят

    Сайт видит

    198.51.100.23
  3. Проверить не удалось

    WebRTC выключен или заблокирован, или ни один STUN-сервер не ответил. Ничего не измерено.

    stun.cloudflare.comНет ответа

    stun.l.google.comНет ответа

    Что здесь показывает большинство инструментовУтечки нет

Запустите дважды

VPN выключен

WebRTC выдал203.0.113.7

Сайт видит203.0.113.7

Утечки нет

VPN включён

WebRTC выдал198.51.100.23203.0.113.7

Сайт видит198.51.100.23

Остался при включённом VPN

Утечка
Каждый результат — с запуском, который к нему приводит. С выключенным VPN адрес WebRTC и адрес, который видит сайт, совпадают; с включённым оба должны измениться, и тот, что остался прежним, и есть ответ.

Защищает ли VPN от утечки WebRTC?

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

Описание самого IETF точно: «если клиент пытается скрыть своё физическое местоположение с помощью виртуальной частной сети (VPN), а VPN и локальная ОС поддерживают маршрутизацию через несколько интерфейсов, WebRTC может обнаружить не только публичный адрес VPN, но и публичный адрес провайдера, через который работает VPN». Передаются оба адреса, и страница, которая их ищет, прочитает оба.

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

VPN включён, Wi-Fi по-прежнему работаетдва интерфейса, два ответа

Ваш ноутбукVPN10.64.0.2Wi-Fi192.168.1.20ТУННЕЛЬ VPNVPN-сервер198.51.100.23Сайтобычный трафикSTUN-серверРоутер (NAT)Ваш провайдер203.0.113.7WebRTC спрашивает через обаВаш ноутбукVPN10.64.0.2Wi-Fi192.168.1.20ТУННЕЛЬ VPNVPN-сервер198.51.100.23Роутер (NAT)Ваш провайдер203.0.113.7обычный трафикСайтSTUN-серверWebRTC спрашивает через оба

Что получает страница

  • 198.51.100.23srflxУвидел STUN-серверчерез VPNСайты его уже видят
  • 203.0.113.7srflxУвидел STUN-серверчерез Wi-Fi, вне туннеляСайты его не видят

RFC 8828

Что закрывает брешь

  • Маршрутизация на уровне операционной системыВне туннеля ничего не уходит, поэтому STUN-сервер видит только адрес VPN.
  • Расширение VPN для браузераОно ограничивает WebRTC внутри браузера, поэтому другой интерфейс никто не спрашивает.
  • Затем проверьте, а не предполагайтеЗапустите эту проверку с включённым VPN. Собственная страница проверки утечек от VPN — не независимое доказательство.
Случай, который IETF описывает в RFC 8828: VPN и операционная система маршрутизируют трафик через несколько интерфейсов, поэтому WebRTC находит публичный адрес VPN и адрес провайдера под ним.

Кандидаты host, server-reflexive и relay: чем они отличаются?

Кандидат типа host — это адрес на вашем собственном устройстве. Кандидат типа server-reflexive — то, что увидел STUN-сервер: публичная сторона вашего NAT. Кандидат типа relay — адрес TURN-сервера, а не ваш.

Это различие важно, а большинство тестов на утечки его отбрасывает. Кандидат типа server-reflexive с вашим публичным IPv4 обычно не новость: это тот же адрес, который сайт получает от подключения, которое вы и так устанавливаете. Кандидат типа host с маршрутизируемым адресом — совсем другое дело: это адрес самого устройства, переданный странице напрямую. Он указывает именно на это устройство, а не только на роутер вашего дома, и меняется при смене сети.

Страница показывает тип рядом с каждым адресом, а также транспорт, порт и связанный адрес, который указывает кандидат типа server-reflexive. Кандидат типа relay — собственный адрес TURN-сервера, и о вас он ничего не говорит; эта проверка не использует TURN-сервер, поэтому если такой кандидат появился, значит, его настроило что-то другое на странице.

Один кандидат, поле за полемкаким его получает страница

  1. candidate:1467250027Основание
  2. 1Компонент
  3. udpТранспорт
  4. 1686052607Приоритет
  5. 203.0.113.7Адрес
  6. 54400Порт
  7. typ srflxТип
  8. raddr 0.0.0.0 rport 9Связанный адрес
  9. generation 0Расширение

Заменён на 0.0.0.0, порт 9, там, где локальные адреса маскируются

Четыре типа

  • typ hostНа этом устройстве

    Адрес на одном из ваших собственных сетевых интерфейсов.

    Частный маскируется. Маршрутизируемый — это само устройство: самая серьёзная находка.

    Серьёзнее всего, если маршрутизируемый

  • typ srflxУвидел STUN-сервер

    Публичная сторона вашего роутера, какой её увидел STUN-сервер.

    Обычно это адрес, который сайт уже получает от вашего подключения.

    Обычно не новость

  • typ prflxУвидела другая сторона

    Публичная сторона вашего роутера, какой её увидела другая сторона звонка.

    Появляется только при соединении с другой стороной, поэтому проверка без звонка его не увидит.

    Только во время звонка

  • typ relayСобственный адрес ретранслятора

    Адрес TURN-сервера, который ретранслирует трафик для вас.

    Адрес сервера, а не ваш. Эта проверка не использует TURN-сервер, так что такой кандидат настроило что-то другое.

    Ничего о вас

Адрес кандидата сравнивается с тем, что видит сайт; его тип показывает, насколько серьёзно расхождение. Определения — из RFC 8445, раздел 4.

Что такое адрес mDNS .local и защищает ли он меня?

Современные браузеры заменяют ваши частные адреса случайным именем, оканчивающимся на .local, прежде чем передать их странице. Это работает — для частных адресов. Скрывать публичный адрес эта замена никогда и не была призвана.

Chrome делает это по умолчанию с версии 76, а в Firefox параметр media.peerconnection.ice.obfuscate_host_addresses имеет значение true: вместо 192.168.1.20 страница получает что-то вроде 8b7f4e2a-….local, что ничего не говорит никому за пределами вашей сети. Safari идёт ещё дальше: пока у сайта нет разрешения на камеру или микрофон, он вообще не предлагает кандидатов типа host. Проверка выше распознаёт такие случайные имена и показывает их как работающую защиту, а не как находку.

Черновик IETF, который определяет этот механизм, прямо говорит, чего он не делает: «адрес, который уже открыт в интернете, не нужно защищать с помощью mDNS, поскольку веб-сервер может без труда его увидеть». Поэтому кандидат типа server-reflexive по-прежнему несёт ваш публичный IPv4, а устройство с маршрутизируемым адресом IPv6 — и это многих удивляет — всё ещё может передать этот адрес как кандидат типа host. Есть ещё одна брешь, о которой стоит знать: Chrome отключает защиту для любого сайта, у которого уже есть разрешение на камеру или микрофон, поэтому сайт видеозвонков, которым вы уже пользовались, видит ваши настоящие локальные адреса.

Что заменяет имя .localи что оно не трогает

Что есть у вашего браузера

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

Что получает страница

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

Что каждый браузер делает по умолчанию

  • ChromeВерсия 76, август 2019 г.
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariНет кандидатов типа host, пока у сайта нет разрешения на камеру или микрофон

Механизм описан в черновике IETF: последняя редакция — декабрь 2021 г., как RFC так и не опубликован. draft-ietf-mmusic-mdns-ice-candidates-03

Адрес, который WebRTC может передатьМаскируется?
192.168.1.20Ваш частный IPv4 как кандидат типа hostМаскируетсяЗаменяется случайным именем: страница ничего не узнаёт о вашей сети.
203.0.113.7Ваш публичный IPv4 как кандидат от STUN-сервераВиденОн и так публичный, поэтому остаётся. Обнуляется только связанный адрес.
2001:db8:4a1f:7c00::1cМаршрутизируемый IPv6 как кандидат типа hostВиденОн тоже публичный, поэтому маскировка на него и не рассчитана.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Временный адрес IPv6Может быть виденЧерновик разрешает браузеру по своему выбору оставлять его без маскировки.
192.168.1.20Любой локальный адрес на сайте с разрешением на камеру или микрофонМаскировка выключенаChrome там отключает маскировку: сайт видит ваши настоящие локальные адреса.
Маскировка скрывает то, что знает только ваша собственная сеть. То, что сайт мог бы увидеть и так, она оставляет как есть: так задумано, это не ошибка.

Почему IPv6 — утечка, которая осталась

Глобальный адрес IPv6 принадлежит одному устройству, а не всему дому за NAT, и mDNS намеренно его не трогает. Из всего, что WebRTC всё ещё выдаёт, именно он лучше всего вас идентифицирует.

В IPv4 NAT домашнего роутера прячет всё за одним адресом, поэтому кандидат типа server-reflexive сообщает странице примерно то же, что и так сообщает ваше обычное подключение. В IPv6 NAT нет: у каждого устройства свой маршрутизируемый адрес, и кандидат типа host с этим адресом указывает на устройство, а не на линию. Если ваш VPN передаёт только IPv4 — а таких много, — этот адрес IPv6 к тому же целиком находится вне туннеля.

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

Кого называет адресте же три устройства, дважды

РоутерIPv4, за NATIPv6, без NAT
Ноутбук192.168.1.202001:db8:4a1f:7c00::1c
Телефон192.168.1.212001:db8:4a1f:7c00::2b
ТВ192.168.1.222001:db8:4a1f:7c00::3d
Роутер203.0.113.7Один адрес на всю линиюСвой адрес у каждого устройства

Глобальный адрес IPv6 из двух половин

2001:db8:4a1f:7c00Префикс сети: ваша линия /64:8d3:5e2f:a41c:9b07Идентификатор интерфейса: это устройство

  • Постоянный2001:db8:4a1f:7c00::1c
  • Временный: меняется2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

VPN, который передаёт только IPv4

  • IPv4198.51.100.23Внутри туннеля
  • IPv62001:db8:4a1f:7c00::1cВне туннеля
За IPv4 NAT весь дом делит один адрес; в IPv6 у каждого устройства свой, и кандидат типа host передаёт его напрямую. Проверка считает маршрутизируемый кандидат типа host с IPv6 самой серьёзной находкой.

Как остановить утечку WebRTC в каждом браузере

В Firefox есть работающие настройки. В Edge — корпоративная политика. Safari и так ограничивает кандидатов. А расширения для браузера, которые до сих пор советуют, больше ничего не делают.

В Firefox параметр media.peerconnection.ice.default_address_only в about:config отправляет только один адрес вместо всех, а media.peerconnection.ice.relay_only ограничивает сбор кандидатами типа relay: прямые звонки перестают работать, зато всё остальное скрыто. Оба по умолчанию выключены; маскировка частных адресов через mDNS (media.peerconnection.ice.obfuscate_host_addresses) уже включена. В Edge политика WebRtcLocalIpsAllowedUrls определяет, каким сайтам можно видеть локальные адреса; в документации самой Microsoft отмечено, что добавление сайта «ослабляет защиту». В Chrome такой настройки для обычного пользователя нет. Safari строже всех, и ничего настраивать не нужно: без разрешения на камеру или микрофон WebKit предлагает только кандидатов типа server-reflexive и relay и вообще никаких кандидатов типа host.

Два средства, которые до сих пор часто советуют, мертвы. Параметр uBlock Origin «Предотвратить утечку локального IP-адреса через WebRTC» удалён в версии 1.38 с пояснением, что он «больше не нужен в современных браузерах, кроме Firefox для Android». А расширение Google WebRTC Network Limiter, которое всё ещё есть в магазине, не может работать: расширения Manifest V2 отключены у всех пользователей Chrome начиная с Chrome 138 в июле 2025 года. Если страница советует установить что-то из этого, её не обновляли годами.

Что предлагает каждый браузерсверено с документацией каждого производителя

  • FirefoxРаботающие настройки

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesПо умолчанию trueМаскирует частные адреса. Уже включено.
    • media.peerconnection.ice.default_address_onlyПо умолчанию falseУстановите trueОтправляет один адрес вместо всех.
    • media.peerconnection.ice.relay_onlyПо умолчанию falseУстановите trueТолько кандидаты типа relay. Скрывает больше всего и ломает прямые звонки.

  • EdgeКорпоративная политика

    WebRtcLocalIpsAllowedUrls

    Список сайтов, которым можно видеть локальные адреса.

    Не настроено: локальные адреса остаются замаскированными.

    Примечание самой Microsoft: добавление сайта ослабляет защиту.

    Windows и macOS, версия 80 и новее

  • ChromeНет настройки

    Нет настройки для обычного пользователя.

    Частные адреса маскируются по умолчанию с версии 76.

    Но не на сайте с разрешением на камеру или микрофон.

  • SafariСтрогий по умолчанию

    Без разрешения на камеру или микрофон — только кандидаты от STUN-сервера и relay.

    Никаких кандидатов типа host.

Советы, которые больше не работают

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Удалён в версии 1.38

    По словам uBlock Origin, больше не нужен в современных браузерах, кроме Firefox для Android.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Всё ещё в магазине, но не может работать

    Расширения Manifest V2 отключены у всех пользователей Chrome начиная с Chrome 138 (июль 2025 г.).

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

Утечка WebRTC, утечка DNS и утечка IP: в чём разница?

Это три разных способа обойти VPN. Утечка WebRTC раскрывает адрес; утечка DNS — то, кто отвечает на ваши запросы имён; утечка IP — простой случай, когда ваш трафик вообще не попал в туннель.

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

Утечка IP в общем смысле — это адрес, который сайт просто видит; его можно проверить на страницах Мой IP адрес или Мой провайдер. Запускайте все три проверки вместе после любых изменений VPN: они ломаются независимо друг от друга, и чистый результат одной ничего не говорит о других.

Три пути в обход VPNкаждый ломается сам по себе

ВыТУННЕЛЬ VPNЧерез туннельУтечка IP · ваш трафикСайт203.0.113.7Утечка DNS · ваши запросыРезолвер провайдера203.0.113.53Утечка WebRTC · ваши адресаСкрипт страницы203.0.113.7ВыТУННЕЛЬ VPNЧерез туннельУтечка IPваш трафикСайт203.0.113.7Утечка DNSваши запросыРезолвер провайдера203.0.113.53Утечка WebRTCваши адресаСкрипт страницы203.0.113.7

  • Утечка IP

    Что утекаетАдрес, который несёт каждый запрос

    Кто это узнаётКаждый сайт, который вы посещаете

    Чем проверитьМой IP адресМой провайдер

  • Утечка DNS

    Что утекаетКакой резолвер отвечает на ваши запросы

    Кто это узнаётВаш провайдер — для каждого сайта, который вы ищете

    Чем проверитьПроверка утечки DNS

  • Утечка WebRTC

    Что утекаетАдреса, которые браузер передаёт странице

    Кто это узнаётЛюбая страница, которая спросит, без запроса разрешения

    Чем проверитьПроверка утечки WebRTC

Они ломаются независимо: чистый результат одной проверки ничего не говорит о двух других. Запускайте все три после любых изменений VPN.

Почему эта проверка опрашивает больше одного STUN-сервера

Потому что «никакой адрес не вернулся» и «никакого адреса нет» выглядят одинаково, а хорошая новость — только одно из них.

Корпоративный файрвол, VPN со строгими ограничениями или сеть, блокирующая UDP, могут не дать STUN-серверу ответить. Проверка, которая спрашивает одного поставщика и ничего не получает, ничего и не узнала, — и всё же обычно в ответ показывают зелёную галочку. Эта проверка опрашивает документированную точку STUN от Cloudflare и сервер Google, показывает ответ каждого отдельно и сообщает, что проверить не удалось, если не ответил ни один из них.

Выбор серверов не случаен. Cloudflare публикует stun.cloudflare.com:3478 как часть продукта, так что есть условия, которые можно прочитать. Сервер Google stun.l.google.com:19302 описан только как сервер по умолчанию в собственном валидаторе WebRTC от Google, без опубликованных условий, поэтому он используется как второе мнение, а не как единственный источник. Сервер Twilio требует учётных данных, а Mozilla не документирует ни одного публичного STUN-сервера, как бы часто его ни упоминали.

Публичные STUN-серверыи какие из них опрашивает эта проверка

  • CloudflareОпрашивается

    stun.cloudflare.com:3478

    Документированная точка подключения, часть продукта, с условиями, которые можно прочитать.

  • GoogleОпрашивается как второе мнение

    stun.l.google.com:19302

    Описан только как сервер по умолчанию в собственном валидаторе WebRTC от Google. Опубликованных условий нет.

  • TwilioНе опрашивается

    global.stun.twilio.com:3478

    Требует учётных данных из API Twilio: открыт не для любой страницы.

  • MozillaНе опрашивается

    Нет публичного сервера

    Не документирует ни одного публичного STUN-сервера. В Firefox вообще нет ICE-серверов по умолчанию.

Когда сервер молчит

CloudflareGoogle
ОтветилОтветилРезультат в силе
ОтветилМолчитРезультат в силе; молчащий сервер назван
МолчитОтветилРезультат в силе; молчащий сервер назван
МолчитМолчитПроверить не удалось
Два оператора, опрошенные по отдельности. Если молчит один сервер, он назван, а результат в силе; если не отвечает ни один, ничего не измерено, и проверка так и говорит, а не показывает успешный результат.

Является ли мой IP-адрес персональными данными?

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

Это дело Breyer, C-582/14, решённое 19 октября 2016 года, и пресс-релиз Суда резюмирует его так: «динамический IP-адрес посетителя является персональными данными по отношению к оператору сайта, если у этого оператора есть законные средства, позволяющие установить личность посетителя с помощью дополнительной информации о нём, которой располагает интернет-провайдер». В том же пресс-релизе отмечено, что у сайта может быть законный интерес хранить часть таких данных, чтобы защищаться от атак.

Именно поэтому эта страница делает свою работу в вашем браузере. ICE-кандидаты собираются вашим браузером, сравниваются в вашем браузере и показываются вам; ни один адрес, найденный WebRTC, не отправляется нам, так что нам нечего хранить, передавать или терять. Пока идёт проверка, можно следить за вкладкой «Сеть» в инструментах разработчика.

Решение по делу BreyerСуд Европейского союза

C-582/14Breyer v Bundesrepublik Deutschland19 октября 2016 г.

  1. Оператор сайтаадрес и время из своих журналов203.0.113.7 · 14:02:37
  2. законные средства их получить
  3. Интернет-провайдеркто пользовался этим адресом в это время203.0.113.7 · 14:02:37 →
  4. Персональные данные — для этого оператора

Пресс-релиз Суда: у сайта может быть законный интерес хранить часть таких данных, чтобы защищаться от атак.

На этой странице

Ваш браузер

  1. Собирает
  2. Классифицирует
  3. Сравнивает
  4. Показывает
  • Видят ваш публичный адрес, как при любом звонке
  • dnsrobot.netНи один кандидат не отправляется
Дело C-582/14, Breyer. Динамический IP-адрес — персональные данные для оператора сайта, у которого есть законные средства установить вашу личность по записям провайдера. Эта страница держит кандидатов в вашем браузере.

Проверка утечки WebRTC: вопросы и ответы

Что такое утечка WebRTC?

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

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

Запустите проверку на этой странице. Она опрашивает три STUN-сервера двух операторов, показывает каждый адрес, выданный WebRTC, с указанием, что это за адрес, и сравнивает маршрутизируемые адреса с тем, который сайт уже видит. Если вы пользуетесь VPN, запустите её один раз с выключенным VPN и один раз с включённым: разница между двумя запусками и есть ответ.

Защищает ли VPN от утечки WebRTC?

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

Что означает адрес .local в результатах?

Это mDNS, и это хорошая новость. Современные браузеры заменяют ваши частные адреса случайным именем, оканчивающимся на .local, прежде чем передать их странице, поэтому из них сайт ничего не узнаёт о вашей домашней сети. Chrome делает это с версии 76, Firefox — тоже; Safari идёт ещё дальше и вообще не предлагает кандидатов типа host, пока у сайта нет разрешения на камеру или микрофон. Проверка показывает такие адреса как работающую защиту, а не как находку.

Если mDNS скрывает мой локальный IP, я в безопасности?

Отчасти. mDNS создан, чтобы скрывать частные адреса, и сознательно не скрывает адрес, который уже публичен, — так сказано в черновике IETF, который его определяет. Ваш публичный IPv4 по-прежнему виден как кандидат типа server-reflexive, а устройство с маршрутизируемым адресом IPv6 всё ещё может передать этот адрес напрямую. Кроме того, Chrome отключает защиту для любого сайта, у которого уже есть разрешение на камеру или микрофон.

Почему проверка иногда сообщает, что проверить не удалось?

Потому что это правда. Если WebRTC выключен, заблокирован расширением или политикой или ни один STUN-сервер не ответил (из-за файрвола, VPN со строгими ограничениями или сети, блокирующей UDP), значит, ничего не измерено. Большинство инструментов в такой ситуации показывают зелёную галочку, а это самое обманчивое, что может сделать проверка на утечки. Эта проверка говорит, что произошло, и называет серверы, которые промолчали.

Как отключить WebRTC в Firefox?

Документированные настройки Firefox ограничивают WebRTC, а не выключают его. В about:config параметр media.peerconnection.ice.default_address_only отправляет один адрес вместо всех, а media.peerconnection.ice.relay_only ограничивает сбор кандидатами типа relay: так скрыто больше всего, но прямые звонки перестают работать. Маскировка частных адресов, media.peerconnection.ice.obfuscate_host_addresses, уже включена по умолчанию. После каждого изменения запускайте проверку снова, чтобы увидеть, что оно дало.

Как остановить утечки WebRTC в Chrome?

Chrome не даёт обычному пользователю такой настройки; маскировка частных адресов через mDNS включена по умолчанию, и это вся защита, которая у вас есть. В Edge, который работает на том же движке, что и Chrome, есть корпоративная политика WebRtcLocalIpsAllowedUrls. Расширения, которые до сих пор часто советуют, не работают: uBlock Origin удалил свой параметр WebRTC в версии 1.38, а WebRTC Network Limiter от Google не может работать с тех пор, как в Chrome 138 отключили Manifest V2.

Чем кандидат типа host отличается от кандидата типа server-reflexive?

Кандидат типа host — это адрес на вашем собственном устройстве. Кандидат типа server-reflexive — то, что увидел STUN-сервер: публичная сторона вашего NAT, обычно тот самый адрес, который сайт уже получил от вашего подключения. Маршрутизируемый кандидат типа host — более серьёзная находка, потому что это адрес самого устройства, а в IPv6 он указывает на устройство, а не на весь дом.

Утечка WebRTC — это то же самое, что утечка DNS?

Нет. Утечка WebRTC раскрывает адрес; утечка DNS раскрывает, какой резолвер отвечает на ваши запросы имён, и тогда провайдер знает каждый сайт, который вы посещаете, даже если сам трафик идёт через VPN. Они ломаются независимо друг от друга, поэтому чистый результат одной ничего не говорит о другой. После любых изменений VPN запустите также нашу Проверку утечки DNS.

Отправляет ли эта проверка мой IP-адрес куда-либо?

Только так же, как его получает любой сайт. Ваш браузер обращается к STUN-серверам, как при любом видеозвонке: в этом и состоит проверка. Чтобы узнать, что видит сайт, страница запрашивает ваши адреса и их сети у ipify.org и у нашего собственного сервера, как это делает Проверка утечки DNS. Адреса, найденные WebRTC, остаются в вашем браузере: ни один из них не отправляется нам. Следите за вкладкой «Сеть» в инструментах разработчика, пока идёт проверка.

Является ли мой IP-адрес персональными данными по праву ЕС?

Для оператора сайта в ЕС динамический IP-адрес является персональными данными, если у этого оператора есть законные средства установить вашу личность с помощью сведений, которые хранит интернет-провайдер. Таково решение Суда Европейского союза по делу Breyer, C-582/14, от октября 2016 года. Это одна из причин, по которым эта страница проводит часть проверки, связанную с WebRTC, в вашем браузере, а не на нашем сервере.

Чего-то не хватает?Предложите функцию или новый инструмент

Похожие инструменты