UDP attraverso la porta SOCKS di Tor: cosa non passa

Puntare un’applicazione a una porta SOCKS funziona per un browser e fallisce per un gioco, e il motivo non è la configurazione. SOCKS5 definisce diversi comandi, e un’implementazione è libera di supportarne solo alcuni; l’interfaccia di Tor accetta connessioni di flusso e risoluzione dei nomi, non l’inoltro arbitrario di datagrammi. Un client che invia UDP e si aspetta che il proxy lo inoltri chiede un comando che il server non implementa. La guida seguente lo verifica in pochi minuti e poi sceglie un trasporto che può davvero funzionare.

Verificate cosa invia davvero l’app

Iniziate identificando il trasporto, non il nome del protocollo. Un client vocale può accedere via HTTPS e poi trasportare i media via UDP; un gioco può autenticarsi via TCP e giocare via UDP; un trasferimento di file può usare TCP per il controllo e UDP per la scoperta. I primi due comportamenti sembrano identici finché l’accesso riesce e la chiamata fallisce ancora, perciò «si è connesso» non è prova che tutta l’app funzioni. Alcuni client tornano anche da soli da UDP a TCP, il che fa sembrare una sessione che funziona in parte una rete instabile invece di un trasporto bloccato.

Annotate la porta di destinazione e il trasporto per la parte che fallisce. Quella sola riga decide se un proxy può aiutare affatto.

Cosa accetterà l’interfaccia SOCKS di Tor

Tor implementa il comando SOCKS5 CONNECT per le connessioni di flusso e comandi di estensione per risolvere i nomi, perciò un browser funziona attraverso di essa senza modifiche. UDP ASSOCIATE, il comando che permetterebbe a un client di consegnare datagrammi al proxy per inoltrarli, non fa parte di ciò che Tor offre. La documentazione delle estensioni è nella specifica delle estensioni SOCKS del progetto, ed è breve. L’assenza di un comando per i datagrammi è deliberata: inoltrare UDP arbitrario darebbe alla rete un ruolo di inoltro per cui non è mai stata progettata.

Questa è anche la risposta per WireGuard, che è UDP per progettazione e non ha un ripiego TCP. Non esiste un percorso supportato che punti WireGuard a una porta SOCKS, e qualunque cosa affermi il contrario è un involucro con la propria storia di fiducia e manutenzione, non una funzione di nessuno dei due strumenti.

OpenVPN è l’eccezione parziale, perché può essere configurato per incapsulare su TCP e comprende un’opzione di proxy SOCKS. Serve comunque un server configurato per TCP e una decisione consapevole sulle conseguenze per prestazioni e impronta, quindi è una scelta di progetto e non una correzione di compatibilità.

Eseguite il controllo in ordine

Confermate prima che il proxy funzioni per i flussi, così che un fallimento successivo non venga attribuito a una porta irraggiungibile. Poi confermate il traffico dell’app stessa, e osservate quali socket apre davvero.

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'

Un primo comando riuscito e un flusso stabilito nella seconda riga mostrano che il percorso del proxy funziona come previsto. Il terzo comando cerca socket di datagrammi locali appartenenti all’app; se il client ne apre uno e invia direttamente a un indirizzo remoto, non ha mai consultato il proxy e nessuna impostazione di proxy lo cambierà. Se fallisce già al primo passo, fermatevi e riparate il percorso del proxy prima di indagare sull’app, perché due guasti insieme producono un rapporto con cui nessuno può agire.

Tornate indietro e scegliete lo strumento giusto

Rimuovete qualsiasi variabile d’ambiente di proxy o impostazione di proxy per applicazione che indirizzasse il client UDP alla porta SOCKS; lasciarle al loro posto rende ambigui i test successivi. Ripristinate la configurazione precedente da una copia, riavviate l’app e confermate che il comportamento originale ritorni perché il confronto sia pulito. Un ritorno indietro che non è verificato è solo la speranza che lo stato sia cambiato.

Per un trasporto che deve restare UDP, una VPN di solito è più adatta: porta i pacchetti dell’app senza chiedere all’app di parlare un protocollo di proxy, al costo di proprietà di anonimato del tutto diverse. Usate ogni strumento per ciò che documenta, e trattate ogni ponte tra loro come un sistema separato che ha bisogno della propria revisione. Annotate nel rapporto finale quale strato porta quale trasporto, così che la persona successiva non riscopra lo stesso confine con un’altra app.