Нултата 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.

Поврзани статии