Java DatagramSocket e inoltro UDP tramite SOCKS5
Capisci perché un socket UDP Java richiede un’implementazione SOCKS5 UDP anche quando le connessioni TCP usano già SOCKS.
La tua richiesta HTTP Java funziona tramite SOCKS, ma una funzione UDP invia ancora traffico direttamente o non riesce. Impostare le proprietà SOCKS della JVM non fornisce a DatagramSocket un’implementazione SOCKS5 UDP.
L’API DatagramSocket invia e riceve datagrammi indirizzati a endpoint di rete. Il suo metodo connect() sceglie un peer per quel socket. Non esegue una negoziazione SOCKS con il peer.
Una rotta UDP SOCKS5 richiede lavoro aggiuntivo
SOCKS5 definisce un’associazione UDP stabilita su una connessione di controllo TCP. Il client scambia poi datagrammi incapsulati con l’indirizzo di inoltro fornito dal proxy. Ogni messaggio incapsulato identifica la propria destinazione. Un’implementazione client deve gestire questo incapsulamento e la durata della connessione di controllo.
Puntare un normale socket UDP sulla porta di ascolto TCP del proxy salta questi passaggi. Inviare i datagrammi grezzi della tua applicazione a quell’indirizzo non sostituisce l’associazione.
Scegli una libreria o una funzione dell’applicazione che supporti esplicitamente l’inoltro UDP SOCKS5 e verifica che anche il server lo supporti. Una libreria che dichiara il supporto SOCKS potrebbe implementare solo TCP CONNECT. La specifica del protocollo distingue i comandi.
Anche l’inoltro UDP richiede un percorso utilizzabile
Una connessione TCP riuscita al proxy stabilisce solo il percorso di controllo. Firewall o comportamenti NAT possono ancora interferire con i datagrammi inviati all’inoltro. Raccogli l’endpoint di inoltro restituito e qualsiasi errore di inoltro prima di concludere che la destinazione dell’applicazione è offline.
Infine, il supporto al trasporto SOCKS non aggiunge garanzie di consegna a UDP. I timeout della tua applicazione, la gestione delle perdite e i limiti di dimensione dei messaggi valgono ancora dopo il cambio di rotta.