Что такое UDP-сетевой посредник и почему некорректная работа с этим протоколом может провоцировать утечки реального IP?

Когда вы покупаете промежуточный сервер, в 90% случаев вы сталкиваетесь с делением по происхождению IP-адреса (серверные, резидентские, ISP или мобильные). Но у любого сетевого посредника есть и вторая, не менее важная характеристика — какие транспортные протоколы он умеет пропускать через себя (HTTP, SOCKS, SSH, UDP).

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

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

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

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

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

• Полный запрет на передачу дейтаграмм UDP операционной системой;

• Принудительный откат сетевого соединения к устаревшему стеку TCP;

• Открытие изолированного сетевого шлюза в обход заданного промежуточного сервера;

• Применение альтернативных системных правил маршрутизации.

В контексте утечки реального IP-адреса угрозу представляет сценарий с формированием параллельного маршрута. Именно через такой параллельный маршрут часть исходящих пакетов и будет отправлена через ваш реальный IP. А теперь давайте подробнее разберем, как именно такая ситуация формируется и как происходит, а также, можно ли от нее защититься.

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

Чем UDP отличается от TCP глазами промежуточного сервера

Чтобы понять, почему пропускать UDP через промежуточный узел сложнее, нужно сравнить логику работы двух транспортных протоколов:

• TCP (Transmission Control Protocol) — работает по четко регламентированному порядку действий, при передаче данных. Прежде чем начать передачу данных, клиент и сервер выполняют между собой трехэтапное рукопожатие (SYN → SYN-ACK → ACK). Во время передачи TCP нумерует каждый пакет с данными, следит за очередностью доставки и, если пакет теряется в процессе передачи, требует у клиента отправить его заново. Для промежуточного сервера это максимально понятная среда: есть четкое начало сессии, понятный канал и явный сигнал закрытия соединения (FIN или RST).

• UDP (User Datagram Protocol) — работает по принципиально иному алгоритму. Здесь нет предварительного рукопожатия, нет постоянной сессии и нет проверки доставки. Клиент просто берет порцию данных (датаграмму), указывает IP-адрес и порт получателя и отправляет. Дошла информация или потерялась по пути — транспортный уровень это не волнует. Основная цель такого подхода увеличить скорость прохождения и снизить задержку (Latency).

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

Зачем нужен UDP-посредник

Еще 5–7 лет назад отсутствие UDP на промежуточном сервере замечали только геймеры и любители стриминга. Для парсинга и работы в браузере хватало обычного TCP. Сегодня ситуация изменилась из-за трех технологий, добавленных в каждый современный браузер:

Протокол HTTP/3 и транспорт QUIC

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

Вот что происходит, когда вы заходите на подобный сайт через антидетект-браузер, но ваш промежуточный сервер не поддерживает UDP:

1. Ваш браузер указал на старте, что он является браузером Chrome. Классический Chrome всегда пытается установить быстрое QUIC-соединение по UDP (порт 443).

2. Промежуточный сервер, который вы подключили к антидетект-браузеру, блокирует UDP-пакеты.

3. Браузер понимает, что UDP не проходит, и принудительно откатывается на старый HTTP/2 по протоколу TCP.

Такое поведение является подозрительным, так как в нормальной ситуации отката не должно произойти, когда речь идет про обычного пользователя, который не использует промежуточный сервер. Но это не утечка, а лишь подозрение со стороны антифрода, он начинает догадываться, что имеет дело с нестандартным поведением, но не может по одному этому признаку заблокировать или сбросить соединение, он понижает траст.

WebRTC и определение реального сетевого окружения

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

Технология WebRTC (отвечает за голосовую/видеосвязь и P2P-передачу данных в браузере) использует протокол STUN/TURN поверх UDP, чтобы узнать ваш реальный внешний IP-адрес и тип NAT.

Если ваш промежуточный сервер не умеет работать с UDP, у вас есть два варианта:

• Либо браузер отправит UDP-запрос к STUN-серверу в обход промежуточного сервера напрямую через ваш роутер (и спалит ваш реальный IP-адрес).

• Либо вам придется принудительно блокировать или подменять WebRTC на уровне браузера. На многих ресурсах (от рекламных кабинетов до банков и криптобирж) отключенный или неспособный пробросить UDP-кандидат WebRTC воспринимается как явный признак бот-активности.

Скорость DNS-запросов

Стандартные DNS-запросы к серверам имен также отправляются короткими UDP-пакетами на 53-й порт. Нативная поддержка UDP позволяет резолвить домены быстрее без лишних затрат времени на установку TCP-сессий.

Как устроен UDP-посредник внутри

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

Поэтому на практике под термином «UDP-посредник» почти всегда скрывается протокол SOCKS5 с функцией UDP ASSOCIATE.

Так как в самом UDP нет понятия «соединения» и в него неудобно встраивать логин с паролем на каждый пакет, была и разработана вот такая схема работы:

1. Управляющий TCP-канал. Сначала ваша программа или браузер подключается к SOCKS5-серверу по обычному TCP, проходит авторизацию по логину и паролю и отправляет специальную команду — 0x03 (UDP ASSOCIATE).

2. Выделение UDP-релея. Промежуточный сервер, видя эту команду, выделяет свободный UDP-порт и отвечает клиенту по TCP, что открыл для него шлюз по адресу X.X.X.X на порту Y.

3. Упаковка и пересылка датаграмм. Клиент берет нужный UDP-пакет, оборачивает его в специальную шапку SOCKS5 (в которой указывает, какому конечному сайту и на какой порт нужно доставить пакет) и отправляет его на указанный порт. Посредник в свою очередь уже пересылает чистый пакет целевому серверу.

4. Привязка к жизни TCP. Управляющее TCP-соединение не закрывается: оно висит в фоне как «страховочный трос». Как только клиент разрывает TCP-сокет, промежуточный сервер понимает, что сессия окончена, и закрывает выделенный UDP-порт.

Кто умеет работать с UDP

Вот как работают с UDP различные протоколы на контрасте друг с другом:

Почему провайдеры отключают UDP на SOCKS5?

Но если стандарт SOCKS5 изначально поддерживает UDP, зачем поставщики принудительно его вырезают? Неужели все дело в экономии средств? На то есть свои причины:

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

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

3. Технические ограничения ротационных P2P-сетей. В динамических резидентских сетевых узлах трафик идет через домашние роутеры и устройства обычных пользователей, которые сами находятся за провайдерским NAT (CGNAT). Пробросить туда полноценную связку UDP ASSOCIATE без потери пакетов не просто технически сложно, но и дорого.

Когда UDP-посредники необходимы, а когда они не нужны?

Где UDP-посредники незаменимы

• Работа через антидетект-браузеры с серьезным антифродом: чтобы браузер общался с сайтами на Cloudflare, Google и Meta по нативному протоколу HTTP/3 (QUIC) и проходил глубокие проверки WebRTC без искусственных заглушек.

• Мобильные эмуляторы и онлайн-игры: игровой трафик, голосовые чаты (Discord, VoIP) и внутренние протоколы мобильных приложений активно используют UDP для минимизации пинга.

• Работа со стримингом и видеопотоками: передача аудио и видео в реальном времени строится поверх UDP-датаграмм.

Где можно обойтись без UDP

• Классический парсинг: подавляющее большинство парсеров собирают данные по стандартным протоколам HTTP/1.1 и HTTP/2 поверх TCP. Переплачивать за поддержку UDP здесь не нужно.

• Работа с REST API и текстовыми вебхуками: все стандартные интеграции с серверными API работают исключительно по TCP.

Для команд, которые уже настроили промежуточные серверы и разделили сетевые профили, Telegram Soft Expert помогает вынести повторяющиеся Telegram-процессы в отдельный рабочий слой: управление аккаунтами, поиск по чатам и каналам, разные типы рассылок и автоответчик. Это позволяет отдельно контролировать транспортный уровень промежуточного сервера и отдельно — операционную работу внутри Telegram.

Как проверить реальную поддержку UDP на вашем SOCKS5

Самый надежный метод, проверить работает ли провайдер с UDP или нет спросить у сервера напрямую при помощи скрипта. Выполнить этот скрипт можно в PowerShell, предварительно прописав данные для подключения (IP, порт, логин и пароль).

& { # Параметры подключения к SOCKS5 $H = "proxy.example.com" $P = 10800 $U = "your_username" $Pass = "your_password"
try { # 1. Управляющий TCP-канал и авторизация (RFC 1928 / RFC 1929) tcp=New-ObjectSystem.Net.Sockets.TcpClient(H, $P) $tcp.ReceiveTimeout = 4000; $tcp.SendTimeout = 4000 $s = $tcp.GetStream() $s.Write([byte[]](5,1,2), 0, 3) buf=New-Objectbyte[]2;[void]s.Read($buf, 0, 2) uB=[Text.Encoding]::ASCII.GetBytes(U); pB=[Text.Encoding]::ASCII.GetBytes(Pass) $auth = [byte[]](1, $uB.Length) + uB+[byte[]](pB.Length) + $pB s.Write(auth, 0, $auth.Length) [void]s.Read(buf, 0, 2) if ($buf[1] -ne 0) { throw "Ошибка авторизации: неверный логин или пароль" }
# 2. Запрос на открытие UDP-шлюза (Команда 0x03) $s.Write([byte[]](5,3,0,1,0,0,0,0,0,0), 0, 10) hdr=New-Objectbyte[]4;[void]s.Read($hdr, 0, 4) if ($hdr[1] -ne 0) { throw "Сервер отклонил UDP ASSOCIATE (код отказа: (hdr[1]))" }
# 3. Парсинг выданного релея (IP и порт) if ($hdr[3] -eq 1) { aB=New-Objectbyte[]4;[void]s.Read($aB, 0, 4); rIp=(aB -join ".") } elseif ($hdr[3] -eq 3) { $len = $s.ReadByte(); $dB = New-Object byte[] len;[void]s.Read($dB, 0, $len) rIp=[Text.Encoding]::ASCII.GetString(dB) } prtB=New-Objectbyte[]2;[void]s.Read($prtB, 0, 2) rPort=(prtB[0] -shl 8) -bor $prtB[1]
# Обход бага NAT/Docker: если сервер вернул локальный IP, шлем на внешний хост $targetIp = $rIp if ($rIp -match '^(0\.|10\.|127\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.)') { $targetIp = $H }
# 4. Отправка сырого STUN-запроса через открытый шлюз к Google STUN (142.250.180.127:19302) $udp = New-Object System.Net.Sockets.UdpClient $udp.Client.ReceiveTimeout = 4000
# Заголовок SOCKS5 UDP + 20 байт STUN Binding Request $socksHdr = [byte[]](0,0,0,1, 142,250,180,127, 0x4B,0x66) $stunReq = [byte[]](0x00,0x01, 0x00,0x00, 0x21,0x12,0xA4,0x42, 1,2,3,4,5,6,7,8,9,10,11,12) $packet = $socksHdr + $stunReq
$sw = [Diagnostics.Stopwatch]::StartNew() [void]udp.Send(packet, $packet.Length, $targetIp, $rPort) $ep = New-Object Net.IPEndPoint([Net.IPAddress]::Any, 0) $res = udp.Receive([ref]ep) $sw.Stop()
Write-Host "[УСПЕХ] UDP полноценно работает! Ответ от WebRTC STUN получен за (sw.ElapsedMilliseconds) мс." -ForegroundColor Green } catch { Write-Host "[ОТКАЗ] UDP не работает: (_.Exception.Message)" -ForegroundColor Red } finally { if ($udp) { $udp.Close() } if ($tcp) { $tcp.Close() } }
}

Если в ответ вы получите конкретный IP-адрес — это значит что провайдер умеет работать с UDP, а если получите в ответ «Отказ», значит не умеет.