Нулевой адрес UDP ASSOCIATE в Indy — не цель датаграммы

Разделяйте адрес клиентской ассоциации, возвращённый релей SOCKS и цель, закодированную в каждом UDP-пакете.

0.0.0.0:0 в запросе Indy UDP ASSOCIATE может быть намеренным. Запрос описывает ожидаемую UDP-точку на стороне клиента, и RFC 1928 допускает нули, когда она неизвестна. Он не выбирает конечную службу.

BND.ADDR/BND.PORT в ответе указывают релей, на который клиент отправляет инкапсулированные датаграммы.

TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target service

В Indy TIdUDPClient.Connect вызывает OpenUDP прозрачного прокси. TIdSocksInfo передаёт поля нулевой ассоциации. Позже SendBuffer передаёт нужную службу в SendToUDP, который строит заголовок назначения SOCKS UDP перед данными приложения.

Если ассоциация успешна, но трафик не идёт, проверьте возвращённый релей, закодированное назначение и путь ответа UDP. NAT/межсетевые экраны могут пропускать обмен TCP, блокируя UDP.

Держите управляющее соединение TCP открытым; его закрытие завершает ассоциацию. В SOCKS4/4a такой операции нет, и одно название SOCKS5 не гарантирует, что сервер поддерживает UDP.

Похожие статьи