L'indirizzo zero di UDP ASSOCIATE in Indy non è la destinazione del datagramma

Distinguere l'indirizzo di associazione del client, il relay SOCKS restituito e la destinazione codificata in ogni pacchetto UDP.

0.0.0.0:0 in una richiesta UDP ASSOCIATE di Indy può essere intenzionale. La richiesta descrive l'endpoint UDP atteso lato client, e la RFC 1928 consente gli zeri quando è sconosciuto. Non seleziona il servizio finale.

Il BND.ADDR/BND.PORT della risposta indica il relay a cui il client invia i datagrammi incapsulati.

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

In Indy, TIdUDPClient.Connect chiama OpenUDP del proxy trasparente. TIdSocksInfo fornisce i campi di associazione a zero. Più tardi, SendBuffer passa il servizio desiderato a SendToUDP, che costruisce l'intestazione di destinazione SOCKS UDP prima dei dati dell'applicazione.

Se l'associazione riesce ma il traffico fallisce, ispezionare il relay restituito, la destinazione codificata e il percorso di risposta UDP. NAT/firewall possono consentire lo scambio TCP bloccando l'UDP.

Mantenere aperta la connessione di controllo TCP; chiuderla termina l'associazione. SOCKS4/4a non hanno questa operazione, e la sola etichetta SOCKS5 non garantisce che un server supporti UDP.

Articoli correlati