Java DatagramSocket et relais UDP SOCKS5

Votre requête HTTP Java passe par SOCKS, mais une fonctionnalité UDP envoie encore le trafic directement ou échoue. Définir les propriétés SOCKS de la JVM ne donne pas à DatagramSocket une implémentation SOCKS5 UDP.

L’API DatagramSocket envoie et reçoit des datagrammes adressés à des points de terminaison réseau. Sa méthode connect() choisit un pair pour ce socket. Elle n’effectue pas de négociation SOCKS avec le pair.

Une route UDP SOCKS5 demande un travail supplémentaire

SOCKS5 définit une association UDP établie sur une connexion de contrôle TCP. Le client échange ensuite des datagrammes encapsulés avec l’adresse de relais fournie par le proxy. Chaque message encapsulé identifie sa destination. Une implémentation cliente doit gérer cet encapsulage et la durée de vie de la connexion de contrôle.

Pointer un socket UDP ordinaire vers le port d’écoute TCP du proxy saute ces étapes. Envoyer les datagrammes bruts de votre application à cette adresse ne remplace pas l’association.

Choisissez une bibliothèque ou une fonctionnalité applicative qui prend explicitement en charge le relais UDP SOCKS5, et confirmez que le serveur le prend aussi en charge. Une bibliothèque qui annonce une prise en charge SOCKS peut n’implémenter que TCP CONNECT. La spécification du protocole distingue ces commandes.

Le relais UDP a aussi besoin d’un chemin utilisable

Une connexion TCP réussie au proxy n’établit que le chemin de contrôle. Les pare-feu ou le comportement du NAT peuvent encore perturber les datagrammes envoyés au relais. Relevez le point de terminaison de relais renvoyé et toute erreur de relais avant de conclure que la destination de l’application est hors ligne.

Enfin, la prise en charge du transport SOCKS n’ajoute aucune garantie de livraison à UDP. Les délais propres à votre application, la gestion des pertes et les limites de taille des messages s’appliquent toujours après le changement de route.