Java DatagramSocket och SOCKS5 UDP-vidarebefordran
Förstå varför en Java UDP-socket behöver en SOCKS5 UDP-implementering även när TCP-anslutningar redan använder SOCKS.
Din Java HTTP-begäran fungerar via SOCKS, men en UDP-funktion skickar fortfarande trafik direkt eller misslyckas. Att ställa in JVM:ens SOCKS-egenskaper ger inte DatagramSocket en SOCKS5 UDP-implementering.
DatagramSocket-API:et skickar och tar emot datagram som är adresserade till nätverksändpunkter. Dess metod connect() väljer en peer för den socketen. Den utför ingen SOCKS-förhandling med peeren.
En SOCKS5 UDP-rutt kräver extra arbete
SOCKS5 definierar en UDP-association som upprättas över en TCP-kontrollanslutning. Därefter utbyter klienten inkapslade datagram med den relay-adress som proxyn anger. Varje inkapslat meddelande anger sitt mål. En klientimplementering måste hantera den inkapslingen och kontrollanslutningens livstid.
Att rikta en vanlig UDP-socket mot proxyns TCP-lyssnarport hoppar över de stegen. Att skicka applikationens råa datagram till den adressen ersätter inte associationen.
Välj ett bibliotek eller en applikationsfunktion som uttryckligen stöder SOCKS5 UDP-relay och bekräfta att servern också gör det. Ett bibliotek som annonserar SOCKS-stöd implementerar kanske bara TCP CONNECT. Protokollspecifikationen skiljer mellan kommandona.
UDP-relayen behöver också en användbar väg
En lyckad TCP-anslutning till proxyn upprättar bara kontrollvägen. Brandväggar eller NAT-beteende kan fortfarande störa datagram som skickas till relayen. Samla in den returnerade relay-ändpunkten och eventuella relay-fel innan du drar slutsatsen att applikationens mål är offline.
Slutligen lägger SOCKS-transportstöd inte till några leveransgarantier för UDP. Applikationens egna timeouts, förlusthantering och begränsningar för meddelandestorlek gäller fortfarande efter att rutten ändrats.