Нулевият адрес за 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.

Подобни статии