Adresa zero UDP ASSOCIATE din Indy nu este destinația datagramei

Separați adresa de asociere a clientului, releul SOCKS returnat și destinația codificată în fiecare pachet UDP.

0.0.0.0:0 într-o cerere Indy UDP ASSOCIATE poate fi intenționat. Cererea descrie punctul final UDP așteptat pe partea clientului, iar RFC 1928 permite zerouri când acesta este necunoscut. Nu selectează serviciul final.

BND.ADDR/BND.PORT din răspuns indică releul către care clientul trimite datagramele încapsulate.

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

În Indy, TIdUDPClient.Connect apelează OpenUDP proxy-ului transparent. TIdSocksInfo furnizează câmpurile de asociere zero. Mai târziu, SendBuffer transmite serviciul dorit către SendToUDP, care construiește antetul de destinație SOCKS UDP înaintea datelor aplicației.

Dacă asocierea reușește dar traficul eșuează, inspectați releul returnat, destinația codificată și calea de răspuns UDP. NAT/firewall-urile pot admite schimbul TCP blocând UDP.

Păstrați conexiunea de control TCP deschisă; închiderea ei încheie asocierea. SOCKS4/4a nu au această operațiune, iar eticheta SOCKS5 singură nu garantează că un server suportă UDP.

Articole similare