Java DatagramSocket en SOCKS5 UDP-relaying
Begrijp waarom een Java UDP-socket een SOCKS5 UDP-implementatie nodig heeft, zelfs wanneer TCP-verbindingen al SOCKS gebruiken.
Je Java HTTP-verzoek werkt via SOCKS, maar een UDP-functie verstuurt verkeer nog steeds rechtstreeks of mislukt. Het instellen van de SOCKS-eigenschappen van de JVM geeft DatagramSocket geen SOCKS5 UDP-implementatie.
De DatagramSocket-API verstuurt en ontvangt datagrammen die aan netwerkeindpunten zijn geadresseerd. De methode connect() kiest een peer voor die socket. Hij voert geen SOCKS-onderhandeling met de peer uit.
Een SOCKS5 UDP-route vraagt extra werk
SOCKS5 definieert een UDP-associatie die over een TCP-besturingsverbinding tot stand komt. Daarna wisselt de client ingekapselde datagrammen uit met het relayadres dat de proxy opgeeft. Elk ingekapseld bericht vermeldt zijn bestemming. Een clientimplementatie moet die inkapseling en de levensduur van de besturingsverbinding afhandelen.
Een gewone UDP-socket op de TCP-luisterpoort van de proxy richten slaat die stappen over. De ruwe datagrammen van je applicatie naar dat adres sturen vervangt de associatie niet.
Kies een bibliotheek of applicatiefunctie die SOCKS5 UDP-relaying uitdrukkelijk ondersteunt, en bevestig dat de server dat ook doet. Een bibliotheek die SOCKS-ondersteuning adverteert, implementeert mogelijk alleen TCP CONNECT. De protocolspecificatie onderscheidt de opdrachten.
De UDP-relay heeft ook een bruikbaar pad nodig
Een geslaagde TCP-verbinding met de proxy legt alleen het besturingspad aan. Firewalls of NAT-gedrag kunnen datagrammen die naar de relay gaan nog steeds verstoren. Verzamel het teruggegeven relayoutpunt en elke relayfout voordat je concludeert dat de bestemming van de applicatie offline is.
Ten slotte voegt SOCKS-transportondersteuning geen leveringsgaranties toe aan UDP. De eigen time-outs van je applicatie, verliesafhandeling en beperkingen op berichtgrootte gelden nog steeds nadat de route is gewijzigd.