Что такое утечка IP через WebRTC? Защита и конфиденциальность

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

Кратко

• Прокси переписывает HTTP-запросы, а сбор кандидатов может идти другим путём, поэтому успешная загрузка страницы ничего не говорит о WebRTC.
• Каждый тип сообщает отдельный факт: host локальный интерфейс, srflx адрес, который увидел STUN-сервер, relay точку TURN, а prflx сопоставление, найденное пиром.
• BotBrowser выбирает список ICE-серверов и раскрываемые сведения о кандидатах через --bot-webrtc-ice, а --bot-webrtc=profile и --bot-webrtc=disabled решают, следует ли WebRTC профилю или исчезает.
• Доказательства выпуска это iceGatheringState в состоянии complete, таблица в chrome://webrtc-internals, совпадающая с утверждённым маршрутом, и getStats() с тем же локальным кандидатом.

Содержание

• Что раскрывает собранный кандидат
• Где заканчивается контроль браузера
• Как BotBrowser работает с ICE-серверами и кандидатами
• Проверка набора кандидатов перед выпуском
• Практическое руководство по решению
• Практический итог

Смотреть видео

В этом англоязычном видео показано, что страница узнаёт из сбора кандидатов RTCPeerConnection ещё до начала любого звонка. Локальная лабораторная страница объявляет три набора кандидатов, один скрипт читает каждый обычным обратным вызовом, а затем лаборатория сравнивает каждый объявленный server-reflexive адрес с объявленным адресом, который видит HTTP. После этого такой же вызов выполнили в официальном Google Chrome с пустым списком ICE-серверов: две строки host-кандидатов на машине с Windows и одна на машине с Ubuntu, в каждой имя mDNS. Видео показывает, что вернули именно эти две машины, а совпадающий список означает согласованность, а не анонимность. Профиль BotBrowser не используется. Озвучка на английском.

Что раскрывает собранный кандидат

Кандидат это один возможный путь для медиа, и его поле type фиксирует, как браузер узнал этот путь: host, srflx, prflx или relay. Обычно Chrome создаёт все четыре при подготовке звонка, и каждый отвечает на свой вопрос о сети за сеансом. Полезный вопрос не в том, существует ли кандидат, а в том, что этот кандидат позволяет странице заключить о машине, маршруте и ответившем ретрансляторе.

Тип	Что узнаёт страница	Поле в chrome://webrtc-internals	Ожидаемое в контролируемом контексте
host	Значение локального интерфейса или имя mDNS, скрывающее его	Строка candidate локального описания	Имя mDNS или значение, заданное профилем
srflx	Публичный адрес, который увидел STUN-сервер	Строка candidate вместе с relatedAddress	Утверждённый выход, а не восходящий канал хоста
relay	Точка TURN, которая понесёт медиа	Строка candidate с typ relay	Присутствует, когда TURN настроен и доступен
prflx	Сопоставление, найденное пиром при проверках	Строка candidate-pair в статистике	Отсутствует или совпадает с утверждённым маршрутом

Таблица важна потому, что развёртывание может пройти по одной строке и не пройти по другой. Профиль, скрывающий значения приватных интерфейсов, всё равно оставляет строки srflx, описывающие фактический выход STUN-запроса, а ретранслятор TURN добавляет второе публичное значение, которое пир увидит во время медиа. Раздельный просмотр четырёх типов делает и отчёт о сбое конкретным: отсутствующая строка relay указывает на запись TURN или путь UDP, а неожиданная строка prflx указывает на сторону пира.

Host-кандидаты и имя mDNS

Кандидаты host описывают сетевой интерфейс машины, на которой работает браузер. Современный Chrome скрывает приватные значения IPv4 и IPv6 за именем mDNS вроде 4f2a9c1e-7b3d-4a52-9e88-1c6d0b8f2e11.local, поэтому страница знает, что интерфейс существует, но не знает значения за ним. Это значимое ограничение, и оно неполное: имя mDNS стабильно в течение жизни профиля, оно появляется в локальном описании и снова появляется в статистике в записи local-candidate. Страница может сравнить два визита и понять, использовался ли один и тот же интерфейс, поэтому mDNS-кандидаты WebRTC и приватность локальной сети рассматривает само имя как пункт проверки, а не закрытый вопрос.

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

Server-reflexive кандидаты и наблюдаемое значение

Кандидаты srflx существуют потому, что браузер отправил запрос привязки STUN на сервер, а ответ указал источник, который этот сервер увидел. Обычный путь использует stun:stun.l.google.com:19302 поверх udp:3478. Ответ несёт сопоставленное публичное значение, а поле relatedAddress сохраняет породившее его локальное значение, поэтому одна строка может содержать обе стороны одного сопоставления.

Строку srflx чаще всего цитируют отчёты об утечках, потому что она описывает то, что хост не выбирал. Когда запрос идёт через утверждённый маршрут, это значение является выходом маршрута. Когда он идёт напрямую, значение является восходящим каналом хоста. Оба результата в списке выглядят одинаково, поэтому проверка должна фиксировать маршрут, а не только значение, и поэтому Согласованность прокси между DNS и WebRTC сравнивает выход HTTP, ответ распознавателя и значение кандидата за один проход.

Кандидаты relay и peer-reflexive

Кандидаты relay появляются, когда сервер TURN настроен и доступен. Браузер выделяет значение на сервере, и медиа затем идут через turn:relay.example.com:3478?transport=udp. Строка называет точку TURN, а не хост, поэтому именно она показывает, что у развёртывания есть путь медиа, не зависящий от локального канала.

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

Где заканчивается контроль браузера

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

Настройки и расширения

Отключение WebRTC в настройках браузера, например через media.peerconnection.enabled в Firefox, полностью убирает сбор. Отсутствие наблюдаемо: страница может проверить, существует ли RTCPeerConnection и разрешается ли createOffer(), а браузер без этого интерфейса выделяется среди тех, кого страница ожидает.

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

Пределы VPN и ретрансляции

VPN переносит все соединения системы в туннель, что меняет то, что видит STUN-сервер, но не то, что перечисляет машина. Строки host по-прежнему описывают локальные интерфейсы, а медиа по-прежнему согласуются с пиром, если только не требуется ретранслятор TURN. Туннель добавляет ещё и второй выход, который развёртывание могло не утвердить, и проверка, смотрящая только на прокси, его пропустит.

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

Как BotBrowser работает с ICE-серверами и кандидатами

BotBrowser меняет список ICE-серверов и сведения о кандидатах, которые раскрывает браузер, используя загруженный профиль вместе с флагами запуска. Средства управления находятся ниже уровня JavaScript, поэтому страница, читающая pc.localDescription или pc.getStats(), получает значения, созданные профилем и флагами.

Три переключателя конфигурации ICE

Переключатель	Что выбирает	Что остаётся вне его
--bot-webrtc-ice="google"	Список серверов stun:stun.l.google.com:19302	Достижимость udp:3478 до этого сервера
--bot-webrtc-ice="custom:..."	Заданный список STUN или TURN	Учётные данные этого ретранслятора
--bot-webrtc=profile	Настройки WebRTC, сохранённые в профиле	Маршрут прокси
--bot-webrtc=disabled	Удаление возможности WebRTC	Ничего: отсутствие видно странице

Различие между двумя семействами стоит сохранять. --bot-webrtc-ice выбирает серверы, а --bot-webrtc выбирает режим. Запуск, задающий только режим, сохраняет список серверов из профиля, а запуск, задающий только список, сохраняет уже записанный режим. Прочитать один из двух и предположить другой именно так развёртывание получает профиль, который выглядит правильным, и сеанс, собирающий кандидатов через другой маршрут.

Флаги и пути через прокси

Обычный запуск сочетает предустановку с прокси и локальной политикой DNS:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server="socks5://user:[email protected]:1080" \
       --bot-webrtc-ice="google" \
       --bot-local-dns \
       --bot-timezone="America/New_York" \
       --bot-locale="en-US"

Собственный список прямо называет серверы STUN и TURN:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server="socks5://user:[email protected]:1080" \
       --bot-webrtc-ice="custom:stun:stun.example.com:3478,turn:turn.example.com:3478?transport=udp"

Автоматизация передаёт те же значения через аргументы запуска:

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      '--bot-profile=path/to/profile.enc',
      '--proxy-server=socks5://user:[email protected]:1080',
      '--bot-webrtc-ice=google',
      '--bot-local-dns',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Пути через ретранслятор

Утверждённый путь медиа должен достигать точки TURN из браузера, и транспорт решает, возможно ли это. Когда прокси-сервис несёт UDP, socks5://user:[email protected]:1080 несёт и трафик STUN с TURN, поэтому запросы страницы и медиа делят один маршрут. Когда сервис несёт только TCP, turn:turn.example.com:3478?transport=udp через него не ответит, и ретранслятор ?transport=tcp нужно утверждать как отдельный путь. UDP через SOCKS5: частная маршрутизация QUIC и WebRTC описывает решения по транспорту для каждого контекста и проверки к ним.

Проверка набора кандидатов перед выпуском

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

Чтение состояния сбора в chrome://webrtc-internals

Откройте chrome://webrtc-internals, запустите тестовую страницу и наблюдайте iceGatheringState. Он проходит от new к gathering и заканчивается на complete. Страница показывает таблицу со строкой на каждого кандидата, столбцом type, полями address, port, protocol и значением relatedAddress. Таблица, которая никогда не доходит до complete, означает, что сбор продолжается или остановился. Таблица, дошедшая до complete только со строками host, означает, что ответ STUN не пришёл.

Сравнение таблицы с pc.getStats()

pc.getStats() возвращает записи local-candidate с полями candidateType, address, port, protocol и relatedAddress, а также записи candidate-pair с полями state, nominated, localCandidateId и remoteCandidateId. Пара с state: succeeded, помеченная как выбранная, является путём, понёсшим медиа. Найдите её localCandidateId и подтвердите, что соответствующая строка local-candidate сообщает тип и значение, которые показала таблица. Два расходящихся представления, например строка таблицы с именем mDNS и статистическая строка с приватным значением IPv4, означают, что страница и медиа использовали разные интерфейсы.

Когда кандидатов relay нет

Состояние complete без строки relay является самым частым сбоем, и этот порядок решает его быстрее всего:

1. В списке серверов нет записи TURN. Тогда таблица показывает только строки host и srflx, что и даёт по замыслу запуск с --bot-webrtc-ice="google".
2. В URL TURN нет ?transport=udp. URL ретранслятора без параметра транспорта откатывается к TCP и молчит на пути, который несёт только UDP.
3. udp:3478 фильтруется на выходе. Выделение TURN никогда не завершается, строка relay не появляется, а chrome://webrtc-internals показывает попытку, закончившуюся без кандидата.
4. Значение --bot-webrtc-ice не совпадает с профилем. Собственный список, называющий хост, которого профиль не допускает, или предустановка без лицензии в развёртывании оставляет запуск со списком, который никто не выбирал, и таблица показывает именно этот список.

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

Практическое руководство по решению

Решайте режим и список серверов вместе, затем проверяйте результат по утверждённому маршруту развёртывания.

1. Сочетайте --bot-webrtc-ice с --proxy-server. Без прокси выход уже является восходящим каналом хоста, и флаг меняет только то, какой сервер его сообщает.
2. Используйте предустановку google, если развёртывание не называет собственную инфраструктуру. stun:stun.l.google.com:19302 это конфигурация большинства трафика, поэтому сеанс без неё выглядит необычно по другой причине.
3. Добавьте --bot-local-dns. Разрешение имён и медиа это два пути, которые чаще всего обходят прокси, и закрытие обоих сокращает проверку.
4. Прибегайте к --bot-webrtc=disabled только там, где у приложения действительно нет медиа-функций. Отсутствующий интерфейс виден, и страница может зафиксировать это различие.
5. Повторяйте проверку из трёх частей после каждой смены точки прокси, поставщика TURN или профиля. Список кандидатов является произведением этих трёх входов.

Ломает ли BotBrowser звонки? Нет, RTCPeerConnection остаётся доступным, и медиа идёт как прежде. Флаги меняют то, какие серверы собирают кандидатов и какие значения получает страница.

В чём разница между двумя флагами? --bot-webrtc-ice выбирает серверы, а --bot-webrtc выбирает, следует ли WebRTC профилю или удаляется.

Достаточно ли VPN? VPN меняет выход для всех соединений, но оставляет строки host и добавляет выход, который развёртывание могло не утвердить.

А IPv6? Применяются те же четыре типа, а значение профиля, покрывающее IPv4 без IPv6, оставляет видимое различие между семействами.

Практический итог

Проверка утечек, читающая только трафик страниц, упускает путь медиа. Зафиксируйте режим, список серверов и утверждённый маршрут; собирайте кандидатов, пока iceGatheringState не сообщит complete; сравните таблицу с getStats(); и храните результат рядом с записью развёртывания. Когда следующий сеанс покажет другую строку, сравнение назовёт изменение, а не оставит проверяющего гадать.

Окружающие сетевые средства управления описаны в материалах Настройка прокси, Защита от утечек DNS и Изоляция браузера для нескольких аккаунтов. Страница возможностей перечисляет связанные функции, а статья о mDNS-кандидатах WebRTC объясняет, что имя mDNS добавляет к строке host.

Открытые источники

• https://botbrowser.io/docs/network/webrtc-leak-prevention/
• https://www.rfc-editor.org/rfc/rfc8445
• https://www.w3.org/TR/webrtc-stats/
• https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection