Утечка WebRTC: как браузер выдаёт ваш настоящий IP

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

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

Что такое WebRTC и зачем он нужен

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

Ключевое слово здесь — «напрямую». Обычная веб-страница общается с сервером по схеме «запрос — ответ»: браузер спросил, сервер отдал. WebRTC устроен иначе: сервер помогает двум участникам найти друг друга, но сам поток по возможности идёт между их устройствами, минуя посредника. Это заметно снижает задержку — в живом разговоре разница между 40 и 200 миллисекундами слышна — и снимает нагрузку с инфраструктуры сервиса, которому иначе пришлось бы перегонять через себя все видеопотоки всех пользователей.

Как браузер узнаёт свой внешний адрес

Чтобы соединить два устройства напрямую, надо решить неочевидную задачу: каждое из них должно понять, по какому адресу оно вообще доступно снаружи. Домашний компьютер обычно не имеет собственного публичного адреса — он находится за NAT роутера и знает только свой локальный адрес вида 192.168.x.x. Сообщать такой адрес собеседнику бессмысленно: у него в домашней сети этот диапазон занят его же устройствами.

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

Роль STUN-сервера

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

Ответ STUN-сервера и есть тот самый публичный IP, который может утечь. Не потому, что его кто-то украл или перехватил: браузер сам его запросил и сам готов передать собеседнику по видеозвонку. Так задумано — без этого адреса прямое соединение просто не установится.

Почему VPN не всегда перехватывает этот запрос

Здесь важная деталь, которую обычно пропускают в объяснениях. VPN-клиент чаще всего работает так: создаёт в системе виртуальный сетевой интерфейс и прописывает маршрут по умолчанию через него. Всё, что приложение отправляет «просто в интернет», не указывая конкретный интерфейс, попадает в туннель.

Но ICE не отправляет запрос «просто в интернет». Он намеренно перебирает все доступные сетевые интерфейсы — Wi-Fi, Ethernet, мобильный модем, виртуальный адаптер VPN — и с каждого пытается получить кандидата. Логика тут не злонамеренная, а инженерная: чем больше вариантов подключения собрано, тем выше шанс, что звонок вообще состоится, и тем точнее алгоритм выберет самый быстрый маршрут. Для видеосвязи это правильное поведение.

Побочный эффект прямо следует из этой логики. Если VPN только добавил маршрут по умолчанию, но не запретил трафик через физический адаптер, STUN-запрос уйдёт и с физического интерфейса тоже. Вернётся настоящий IP от вашего провайдера — и он окажется в списке кандидатов наравне с адресом VPN-сервера. Дальше страница, на которой вы находитесь, может прочитать этот список средствами обычного JavaScript: для сбора кандидатов не нужно ни разрешения на камеру, ни разрешения на микрофон. Отпечаток браузера: как вас узнают без cookie.

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

Какие адреса могут утечь

Локальный адрес — внутренний адрес устройства в домашней или офисной сети, вроде 192.168.1.42. Сам по себе он не указывает, кто вы, но говорит о структуре вашей сети и служит дополнительным штрихом в наборе признаков, по которым вас можно отличить от других посетителей.
Публичный адрес — тот, что вернул STUN-сервер. Это главная потеря: именно по нему определяют провайдера, город и страну, и именно его должен был скрыть VPN.
Адрес VPN-сервера — он тоже попадает в список кандидатов, и это нормально. Проблема не в его наличии, а в соседстве с реальным адресом.
Адрес TURN-ретранслятора — промежуточного сервера, через который идёт поток, если прямое соединение установить не удалось. Ваш IP он не раскрывает, но по нему видно, каким сервисом связи вы пользуетесь.

Что изменилось за последние годы

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

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

Как проверить утечку за минуту

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

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

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

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

Способов три, и они принципиально разного качества.

Настройки браузера

В Firefox механизм отключается напрямую: на служебной странице about:config есть параметр media.peerconnection.enabled, перевод которого в false выключает WebRTC целиком. Рядом лежат более мягкие параметры, ограничивающие сбор кандидатов одним адресом по умолчанию, — они оставляют звонки рабочими и при этом сокращают то, что браузер готов рассказать о ваших интерфейсах.

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

Расширения-блокировщики

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

Область действия — один браузер. Расширение не влияет на второй браузер, на приложения вне браузера и, как правило, на встроенные веб-окна внутри других программ.
Оно меняет настройку, а не маршрут. Расширение просит браузер вести себя иначе; оно не блокирует трафик мимо туннеля на уровне системы, поэтому любая ситуация, где настройка не применилась, снова открывает канал.
Права шире, чем задача. Многие такие расширения просят разрешения куда более широкие, чем нужно для изменения одного параметра, — а расширение с доступом ко всем страницам видит куда больше, чем ваш IP.
Оно живёт своей жизнью. Сменился владелец, вышло обновление, отключился автозапуск после переустановки браузера — и защиты нет, а внешне ничего не изменилось.

Защита на стороне VPN-клиента

Принципиально надёжнее решать задачу там, где она возникает, — на уровне маршрутизации и правил файрвола. Клиент, который не просто добавляет маршрут по умолчанию, а закрывает исходящий трафик мимо туннеля, отсекает STUN-запрос с физического интерфейса на подходе. Браузеру при этом ничего не нужно объяснять: кандидат с реального адреса просто не соберётся, потому что пакет никуда не уйдёт.

Такая защита работает одинаково во всех браузерах и во всех приложениях сразу и не зависит от того, помните ли вы про расширение. По той же причине системный VPN-клиент с Kill Switch надёжнее, чем браузерное расширение VPN: последнее в принципе не управляет трафиком за пределами своей вкладки.

Чего VPN здесь не закроет

Отдельно стоит сказать о границах — не для того, чтобы обесценить защиту, а чтобы вы не строили на ней ожиданий, которых она не выдержит.

Закрытая утечка WebRTC означает ровно одно: сайт не увидит ваш настоящий IP по этому каналу. Она не означает, что вас нельзя опознать. Если вы залогинены в аккаунт — почты, соцсети, маркетплейса, — то с этого момента IP перестаёт быть главным идентификатором: сервис знает, кто вы, потому что вы сами ему представились. Смена адреса тут ничего не меняет.

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

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

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

Нужно ли отключать WebRTC совсем?

Обычно нет. Полное отключение ломает видеозвонки и голосовые чаты в браузере, а задачу решает ограничение сбора кандидатов или корректная маршрутизация на стороне VPN-клиента. Полное отключение имеет смысл, если вы вообще не пользуетесь звонками в браузере.

Утечка WebRTC — это уязвимость браузера?

Нет. Это штатное поведение протокола: браузер намеренно собирает адреса со всех сетевых интерфейсов, чтобы соединение с собеседником вообще состоялось. Проблемой это становится только в сочетании с VPN, который не блокирует трафик мимо туннеля.

Если WebRTC-тест показал только адрес VPN-сервера, всё в порядке?

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

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