UDP-прокси и протокол QUIC — как утекает реальный IP

Среди тех, кто работает с мультиаккаунтингом, да и вообще использует прокси, существует такая страшилка: если приложение, через которое вы проксируете трафик (читай — антидетект-браузер), не поддерживает UDP (или базово не контролирует сетевые маршруты), ваш реальный IP-адрес может утечь — и тогда сама идея использования прокси теряет смысл. Вы хотите скрыть реальный IP-адрес, но из-за отсутствия поддержки UDP, наоборот, раскрываете его. 

А какая страшилка при прочих равных будет чуточку страшнее остальных? Та, которая основана на реальных событиях. Вот и в утверждении выше все-таки есть доля правды. 

Реальный IP-адрес и правда может утечь.

Один из возможных сценариев — вы купили прокси с поддержкой UDP, но используемый вами антидетект-браузер не умеет корректно работать с UDP-трафиком.

При этом утверждение «нет поддержки UDP, и ваш IP 100% утекает» некорректно. Правильнее сказать так: «нет поддержки UDP — появляется неконтролируемое сетевое поведение».

Под неконтролируемым сетевым поведением понимается один из нескольких сценариев:

• UDP не работает совсем 

• соединение откатывается на TCP

• соединение получает отдельный сетевой маршрут, который не проходит через текущий прокси

• используется другой механизм маршрутизации 

При использовании отдельного сетевого маршрута и возникает риск утечки реального адреса, когда часть трафика может пойти другим путем и потенциально раскрыть ваш реальный IP-адрес. 

Привет! Я Александр, пишу для антидетект-браузера Aurorium и по совместительству являюсь специалистом в вопросах автоматизации и парсинга. В этом материале мы рассмотрим, что такое UDP-прокси, чем протокол UDP отличается от TCP и как ваш реальный IP-адрес может утечь, если антидетект-браузер не умеет работать с UDP. По традиции сварите себе чашечку кофе или заварите чай, приготовьте пару бутербродов — мы начинаем!

Что такое UDP-прокси? 

Что такое прокси-сервер, знают уже даже наши родители и родители наших родителей — это посредник между вашим устройством и целевым сайтом. 

Исторически так сложилось, что большинство базовых прокси (HTTP/HTTPS) умеют маршрутизировать только TCP-трафик, и на этом уровне они отлично справляются с загрузкой текстовых данных, HTML-кода или картинок.

Но такие прокси не подходят для решения специфических задач — стриминга, звонков, онлайн-игр или работы современных сетевых протоколов (где как раз и используется протокол UDP). Прокси, поддерживающие TCP-трафик, физически не умеют передавать такие пакеты.

UDP-прокси (чаще всего это сервер с поддержкой протокола SOCKS5 и активированной функцией UDP Associate) — это прокси, который способен инкапсулировать, маршрутизировать и отдавать UDP-датаграммы.

И вот тут возникает второй закономерный вопрос: зачем вообще браузеру нужен UDP и откуда берется этот отдельный сетевой маршрут? И не проще ли просто модернизировать (как-то докрутить) и использовать TCP вообще для любых подключений? 

Давайте разбираться!

Зачем браузеру нужен UDP?

Итак, где именно поддержка UDP становится важна для браузера и, соответственно, для антидетект-браузера?

Давайте рассмотрим, что современный браузер делает помимо обычной загрузки страницы. 

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

Браузер одновременно решает несколько задач: грузит страницу, устанавливает дополнительные соединения, а иногда и организует потоковую или мультимедийную передачу данных (те самые звонки, стриминг и онлайн-игры). Для всех этих задач транспорт может быть разным.

Самый очевидный пример — протокол HTTP/3. В отличие от HTTP/1.1 и HTTP/2, он работает не поверх TCP, а поверх протокола QUIC. А QUIC, в свою очередь, использует UDP.

Выглядит это так:

HTTP/1.1 → TCP
HTTP/2   → TCP
HTTP/3   → QUIC → UDP

HTTP/3 — это новая версия HTTP, как и HTTP/1.1 или HTTP/2, но с другим транспортом. Это не «ускоренный UDP», а HTTP, работающий поверх протокола QUIC.

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

HTTP/3 → QUIC → UDP → IP.

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

HTTP/3 не единственный пример; есть еще более опасный (с точки зрения утечек IP-адреса) — WebRTC. Когда сайт устанавливает голосовое или видеосоединение, браузер использует ICE для поиска подходящего сетевого пути. В этом процессе может использоваться UDP-соединение со STUN/TURN-серверами.

ICE (Interactive Connectivity Establishment) — механизм поиска и выбора подходящего сетевого пути между участниками WebRTC. В процессе ICE браузер собирает и проверяет различные варианты соединения, в том числе адреса, полученные через STUN, и relay-адреса TURN. 

И вот здесь появляется связь между WebRTC и антидетектом: если браузер получает возможность использовать UDP-маршрут, который не проходит через установленный пользователем прокси, этот маршрут может отличаться от маршрута обычного HTTP-трафика. 

Может возникнуть такая ситуация, что весь трафик будет идти через прокси, а UDP пойдет через ваш реальный IP-адрес.

TCP против UDP, а может просто заменить один на другой?

Давайте разберем более предметно два протокола, чем и почему они отличаются, чтобы понять, в чем UDP лучше TCP. 

TCP отвечает за надежную и упорядоченную передачу данных. В процессе работы происходит: 

• установление соединения;

• контроль порядка пакетов;

• обнаружение потерь и при необходимости повторная передача пакетов.

Поверх TCP-протокола все время строилась и продолжает строиться большая часть привычного веб-трафика.

UDP устроен иначе. Он не устанавливает соединение, как это делает TCP, не гарантирует доставку каждой отдельной датаграммы и не контролирует порядок их получения.

За счет этого UDP предоставляет приложению (сайту) более простой транспорт с меньшим количеством встроенной транспортной логики. А все, что требуется конкретному протоколу поверх него — подтверждение доставки, восстановление после потерь или управление несколькими потоками, — может быть реализовано на уровне выше. 

Именно так и работает QUIC.

QUIC использует UDP как базовый транспорт, а поверх него реализует собственную транспортную логику: надежную передачу потоковых данных, контроль перегрузки, восстановление после потерь, шифрование и работу с несколькими независимыми потоками. 

Получается что QUIC — это TCP на максималках, построенный поверх UDP. Так это выглядит, да, но у него уже нет тех ограничений, которые присущи TCP.

Для большей наглядности сравним два протокола по отношению друг к другу в таблице:

Почему QUIC — это не тоже самое, что и TCP-протокол и чем он опасен для прокси?

QUIC проектировался так, чтобы взять все лучшее от TCP (надежность), но убрать его ограничения. Вот что получил QUIC:

1. 0-RTT — QUIC объединяет транспортное и криптографическое рукопожатие. При повторном подключении к сайту браузер начинает передавать данные почти мгновенно.

2. Независимые потоки — в TCP потеря одного пакета (например, куска CSS) блокирует загрузку всего остального (HTML, скриптов). В QUIC потоки независимы: потеряли картинку — остальной сайт продолжает грузиться.

3. Миграция соединения — в TCP-протоколе сессия привязана к IP-адресу. Переключились с Wi-Fi на LTE — соединение оборвется. В QUIC сессия привязана к Connection ID. Вы можете менять сети, а условное видео на YouTube продолжит воспроизводиться без потери качества и переподключения.

Способность QUIC «выживать» при смене сетей и восстанавливать сессии означает, что протокол умеет переживать изменение сетевого пути. Если ваше соединение с прокси на секунду моргнет, браузер (в рамках миграции соединения QUIC) может попытаться восстановить сессию напрямую через ваш реальный сетевой интерфейс, в обход отвалившегося прокси. Если антидетект не контролирует сетевой слой, ваш реальный IP-адрес улетит серверу, а значит, и антифрод сможет его увидеть.

WebRTC — где появляется риск утечки IP

Если прокси умеет работать только с TCP, браузер не сможет провести через него QUIC-трафик привычным способом. HTTP/3 в такой ситуации просто не поднимется, а браузер продолжит работу через HTTP/2. 

Вроде ничего критичного, откатился и откатился, что бубнить-то? Но если смотреть с точки зрения антифрода, тут есть за что зацепиться. 

Когда сайт поддерживает протокол HTTP/3 (а у серверов Google и Meta он стоит по умолчанию), обычный пользователь с прямым интернет-подключением зайдет на него именно по QUIC (UDP). Если же браузер из-за настроенного прокси не справляется с UDP и внезапно откатывается на устаревший протокол поверх TCP — антифрод видит сетевую аномалию и, скорее всего, ваш Fraud Score станет хуже. 

С WebRTC ситуация интереснее.

Представим обычный профиль созданный в антидетект-браузере, с установленным прокси:

Реальный IP:
91.xxx.xxx.xxx
IP прокси:
185.xxx.xxx.xxx

При открытии сайта он увидит не ваш IP, а адрес прокси:

Браузер
  ↓
Прокси
  ↓
 Сайт
Сайт видит:
185.xxx.xxx.xxx

С точки зрения пользователя все логично и максимально защищено — реальный IP скрыт. С точки зрения сайта, кстати, тоже.

Усложняем ситуацию и добавляем новую вводную — на странице используется WebRTC.

Что делает WebRTC

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

Для этого используется ICE.

С помощью ICE браузер собирает возможные комбинации IP-адресов и портов, через которые можно установить соединение. Среди них может быть и ваш реальный IP-адрес.

Условно:

ICE
 ├── локальный адрес
 ├── публичный адрес через STUN
 └── адрес relay через TURN

Затем ICE проверяет доступные варианты и выбирает рабочую пару адресов. В базовом варианте ICE для таких проверок используется UDP.

Где здесь появляется прокси

А теперь возвращаемся к антидетекту.

Если ваш антидетект-браузер умеет проксировать только HTTP/TCP, он физически не может контролировать UDP-трафик, который использует WebRTC.

В результате браузер разделяет трафик на два независимых маршрута:

1. Обычный HTTPS-трафик (идет через прокси):

Браузер
   ↓ TCP
Прокси
   ↓
Сайт
(Сайт видит IP прокси: 185.xxx.xxx.xxx)

2. WebRTC-трафик (идет в обход прокси): 

WebRTC:
Браузер
 ↓ UDP
Сетевой интерфейс
  ↓
STUN / WebRTC

И это может привести к такой картине, где возникает потенциальная утечка реального IP-адреса:

HTTP:
185.xxx.xxx.xxx  ← IP прокси
WebRTC:
(Сайт видит ваш реальный домашний IP: 91.xxx.xxx.xxx)

И вот ваш реальный IP-адрес утек. Мало того, что сайт видит две разные сетевые идентичности в рамках одного профиля, так еще и антифрод замечает использование прокси и блокирует (или ограничивает) аккаунт. Но и это не всё. Если у вас несколько аккаунтов и все они будут связаны по вашему реальному IP-адресу в сеть, вы оказываетесь в той точке, где ситуация перестает быть томной.

При этом важно понимать: само по себе наличие WebRTC на сайте не означает гарантированной утечки. Но если антидетект не контролирует UDP-маршруты, вы даете сайту (а значит и антифроду) возможность нащупать ваш прямой сетевой путь.

Фейковая галочка vs Реальная маршрутизация

Проблема рынка в том, что многие расширения и базовые антидетект-браузеры указывают, что поддерживают UDP, хотя на деле просто принудительно отключают WebRTC в браузере или откатываются на HTTP/2 при встрече с HTTP/3 (для пользователя это же вообще незаметно). 

Настоящая поддержка UDP не реализуется на уровне браузера. Она делается на уровне сетевого стека операционной системы.

Чтобы WebRTC-кандидаты не смогли «нащупать» ваш реальный Wi-Fi или Ethernet, антидетект-браузер должен использовать виртуальный сетевой интерфейс (TUN-режим) или глубокий перехват сокетов. В таком сценарии весь трафик системы (и TCP, и UDP) принудительно заворачивается в туннель. ICE-кандидаты просто не видят вашего реального железа — для них существует только туннель к вашему прокси (который, конечно же, тоже должен поддерживать UDP, например, SOCKS5).

И здесь мы сталкиваемся с главной проблемой рынка прокси — дефицитом и дороговизной решений с реальной поддержкой UDP-протокола. Большинство поставщиков либо вообще не поддерживают UDP, либо продают такие прокси по завышенным тарифам. Но даже если вы нашли провайдера с честным UDP, появляется проблема: движок Chromium «из коробки» умеет работать с UDP напрямую, но не умеет его проксировать через стандартный SOCKS5. Без глубокой проработки движка любой базовый антидетект-браузер будет отправлять через SOCKS5 обычный TCP-трафик. 

Как мы решили эту проблему в Aurorium Browser

Мы переработали сетевой стек и добавили честную поддержку UDP-протокола. Наша архитектура имеет нативную поддержку UDP-протокола. Если ваш прокси изначально умеет передавать UDP-пакеты, Aurorium автоматически распознает протокол и направляет QUIC и WebRTC-трафик напрямую через прокси без потерь.

В результате целевой сайт видит естественное поведение: сессии поднимаются по HTTP/3 (QUIC), WebRTC отрабатывает без ошибок, а ваш реальный IP не утекает и остается скрыт за туннелем.

Как проверить свой антидетект-браузер прямо сейчас:

1. Включите ваш рабочий профиль с прокси.

2. Если хотите проверить QUIC, перейдите на страницу — https://browserleaks.com/quic, для тестирования UDP — https://networktest.twilio.com/.

Если QUIC поддерживается вы увидите примерно такую картину.

Если QUIC не поддерживается, то такую:

Когда проверяете UDP то видите примерно такую картину, если UDP поддерживается

Проксируйте трафик с умом и проверяйте инструменты, которыми пользуетесь.