UDP via le port SOCKS de Tor : ce qui ne passe pas

Pointer une application vers un port SOCKS fonctionne pour un navigateur et échoue pour un jeu, et la raison n’est pas la configuration. SOCKS5 définit plusieurs commandes, et une implémentation est libre de n’en prendre en charge que quelques-unes ; l’interface de Tor accepte les connexions de flux et la résolution de noms, pas le relais arbitraire de datagrammes. Un client qui envoie de l’UDP et attend du proxy qu’il le relaie demande une commande que le serveur n’implémente pas. Le guide ci-dessous le vérifie en quelques minutes, puis choisit un transport qui peut réellement fonctionner.

Vérifiez ce que l’application envoie réellement

Commencez par identifier le transport plutôt que le nom du protocole. Un client vocal peut se connecter via HTTPS puis transporter les médias via UDP ; un jeu peut s’authentifier via TCP et jouer via UDP ; un transfert de fichiers peut utiliser TCP pour le contrôle et UDP pour la découverte. Les deux premiers comportements semblent identiques jusqu’à ce que la connexion réussisse et que l’appel échoue encore, et c’est pourquoi « c’est connecté » ne prouve pas que toute l’application fonctionne. Certains clients reviennent aussi d’eux-mêmes de l’UDP au TCP, ce qui fait ressembler une session partiellement fonctionnelle à un réseau instable plutôt qu’à un transport bloqué.

Notez le port de destination et le transport pour la partie qui échoue. Cette seule ligne décide si un proxy peut aider, ne serait-ce qu’un peu.

Ce que l’interface SOCKS de Tor acceptera

Tor implémente la commande SOCKS5 CONNECT pour les connexions de flux et des commandes d’extension pour résoudre les noms, ce qui explique qu’un navigateur y fonctionne sans modification. UDP ASSOCIATE, la commande qui permettrait à un client de remettre des datagrammes au proxy pour les relayer, ne fait pas partie de ce que Tor propose. La documentation des extensions se trouve dans la spécification des extensions SOCKS du projet, et elle est courte. L’absence d’une commande pour les datagrammes est délibérée : relayer de l’UDP arbitraire donnerait au réseau un rôle de relais pour lequel il n’a jamais été conçu.

C’est aussi la réponse pour WireGuard, qui est de l’UDP par conception et n’a pas de repli TCP. Aucun chemin pris en charge ne pointe WireGuard vers un port SOCKS, et tout ce qui prétend le contraire est une enveloppe avec sa propre histoire de confiance et de maintenance, pas une fonctionnalité de l’un ou l’autre des deux outils.

OpenVPN est l’exception partielle, car il peut être configuré pour tunneliser via TCP et il comprend une option de proxy SOCKS. Cela exige tout de même un serveur configuré pour TCP et une décision assumée sur les conséquences en matière de performance et d’empreinte, donc c’est un choix de conception et non un correctif de compatibilité.

Exécutez la vérification dans l’ordre

Confirmez d’abord que le proxy fonctionne pour les flux, afin qu’un échec ultérieur ne soit pas imputé à un port injoignable. Confirmez ensuite le trafic propre de l’application, et regardez quels sockets elle ouvre réellement.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

Une première commande réussie et un flux établi à la deuxième ligne montrent que le chemin du proxy fonctionne comme prévu. La troisième commande cherche des sockets de datagrammes locaux appartenant à l’application ; si le client en ouvre un et envoie directement vers une adresse distante, il n’a jamais consulté le proxy et aucun réglage de proxy n’y changera rien. Si cela échoue dès la première étape, arrêtez-vous et réparez le chemin du proxy avant d’enquêter sur l’application, car deux défauts à la fois produisent un rapport avec lequel personne ne peut agir.

Revenez en arrière et choisissez le bon outil

Supprimez toute variable d’environnement de proxy ou tout réglage de proxy par application qui orientait le client UDP vers le port SOCKS ; les laisser en place rend les tests suivants ambigus. Restaurez la configuration précédente depuis une copie, redémarrez l’application et confirmez que le comportement d’origine revient pour que la comparaison soit propre. Un retour arrière qui n’est pas vérifié n’est qu’un espoir que l’état a changé.

Pour un transport qui doit rester en UDP, un VPN convient généralement mieux : il transporte les paquets de l’application sans demander à celle-ci de parler un protocole de proxy, au prix de propriétés d’anonymat entièrement différentes. Utilisez chaque outil pour ce qu’il documente, et traitez tout pont entre eux comme un système distinct qui a besoin de sa propre revue. Notez dans le rapport final quelle couche transporte quel transport, pour que la personne suivante ne redécouvre pas la même frontière avec une autre application.