UDP a través del port SOCKS del Tor: què no passa

Dirigir una aplicació a un port SOCKS funciona per a un navegador i falla per a un joc, i el motiu no és la configuració. SOCKS5 defineix diverses ordres, i una implementació és lliure de suportar-ne només algunes; la interfície del Tor accepta connexions de flux i resolució de noms, no el reenviament arbitrari de datagrames. Un client que envia UDP i espera que el proxy el retransmeti demana una ordre que el servidor no implementa. La guia següent ho comprova en pocs minuts i després tria un transport que realment pugui funcionar.

Comproveu què envia realment l’aplicació

Comenceu identificant el transport, no el nom del protocol. Un client de veu pot iniciar sessió per HTTPS i després portar el mitjà per UDP; un joc pot autenticar-se per TCP i jugar per UDP; una transferència de fitxers pot fer servir TCP per al control i UDP per al descobriment. Els dos primers comportaments semblen idèntics fins que l’inici de sessió té èxit i la trucada continua fallant, i per això «s’ha connectat» no és prova que tota l’aplicació funcioni. Alguns clients també tornen de UDP a TCP per si sols, cosa que fa que una sessió que funciona parcialment sembli una xarxa inestable en lloc d’un transport bloquejat.

Anoteu el port de destinació i el transport de la part que falla. Aquesta única línia decideix si un proxy pot ajudar gens.

Què acceptarà la interfície SOCKS del Tor

El Tor implementa l’ordre SOCKS5 CONNECT per a connexions de flux i ordres d’extensió per resoldre noms, i per això un navegador hi funciona sense canvis. UDP ASSOCIATE, l’ordre que permetria a un client lliurar datagrames al proxy perquè els reenviï, no forma part del que ofereix el Tor. La documentació de les extensions és a l’especificació d’extensions SOCKS del projecte, i és curta. L’absència d’una ordre per a datagrames és deliberada: reenviar UDP arbitrari donaria a la xarxa un paper de reenviament per al qual mai no es va dissenyar.

Aquesta és també la resposta per a WireGuard, que és UDP per disseny i no té alternativa TCP. No hi ha cap camí admès que apunti WireGuard a un port SOCKS, i qualsevol cosa que afirmi el contrari és un embolcall amb la seva pròpia història de confiança i manteniment, no una característica de cap de les dues eines.

OpenVPN és l’excepció parcial, perquè es pot configurar per tunelar per TCP i entén una opció de proxy SOCKS. Això encara requereix un servidor configurat per TCP i una decisió conscient sobre les conseqüències de rendiment i d’empremta, així que és una elecció de disseny i no una solució de compatibilitat.

Executeu la comprovació per ordre

Confirmeu primer que el proxy funciona per a fluxos, perquè una fallada posterior no es pugui atribuir a un port inabastable. Després confirmeu el trànsit propi de l’aplicació i observeu quins sockets obre realment.

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'

Una primera ordre correcta i un flux establert a la segona línia mostren que el camí del proxy funciona tal com es va dissenyar. La tercera ordre busca sockets de datagrames locals que pertanyin a l’aplicació; si el client n’obre un i envia directament a una adreça remota, mai no ha consultat el proxy i cap paràmetre de proxy ho canviarà. Si falla al primer pas, atureu-vos i repareu el camí del proxy abans d’investigar l’aplicació, perquè dos errors alhora produeixen un informe amb què ningú no pot actuar.

Revertiu i trieu l’eina correcta

Elimineu qualsevol variable d’entorn de proxy o paràmetre de proxy per aplicació que apuntés el client UDP al port SOCKS; deixar-los al seu lloc fa ambigus els tests posteriors. Restaureu la configuració anterior des d’una còpia, reinicieu l’aplicació i confirmeu que el comportament original torna perquè la comparació sigui neta. Una reversió que no es verifica només és una esperança que l’estat hagi canviat.

Per a un transport que ha de romandre UDP, una VPN sol ser més adequada: porta els paquets de l’aplicació sense demanar-li que parli un protocol de proxy, a costa d’propietats d’anonimat completament diferents. Utilitzeu cada eina per allò que documenta, i tracteu qualsevol pont entre elles com un sistema separat que necessita la seva pròpia revisió. Anoteu a l’informe final quina capa porta quin transport, perquè la persona següent no redescobreixi la mateixa frontera amb una aplicació diferent.