UDP prin portul SOCKS al Tor: ce nu trece

Direcționarea unei aplicații către un port SOCKS funcționează pentru un browser și eșuează pentru un joc, iar motivul nu este configurația. SOCKS5 definește mai multe comenzi, iar o implementare este liberă să accepte doar unele dintre ele; interfața Tor acceptă conexiuni de flux și rezolvarea numelor, nu redirecționarea arbitrară a datagramelor. Un client care trimite UDP și așteaptă ca proxy-ul să îl redirecționeze cere o comandă pe care serverul nu o implementează. Ghidul de mai jos verifică acest lucru în câteva minute și apoi alege un transport care poate funcționa cu adevărat.

Verificați ce trimite de fapt aplicația

Începeți prin a identifica transportul, nu numele protocolului. Un client vocal se poate autentifica prin HTTPS și apoi poate transporta media prin UDP; un joc se poate autentifica prin TCP și poate juca prin UDP; un transfer de fișiere poate folosi TCP pentru control și UDP pentru descoperire. Primele două comportamente par identice până când autentificarea reușește și apelul tot eșuează, de aceea „s-a conectat” nu este dovada că întreaga aplicație funcționează. Unele clienturi revin singure de la UDP la TCP, ceea ce face o sesiune care funcționează parțial să pară o rețea instabilă în loc de un transport blocat.

Notați portul de destinație și transportul pentru partea care eșuează. Acea singură linie decide dacă un proxy poate ajuta deloc.

Ce va accepta interfața SOCKS a Tor

Tor implementează comanda SOCKS5 CONNECT pentru conexiuni de flux și comenzi de extensie pentru rezolvarea numelor, de aceea un browser funcționează prin ea fără modificări. UDP ASSOCIATE, comanda care i-ar permite unui client să predea datagramele proxy-ului pentru redirecționare, nu face parte din ceea ce oferă Tor. Documentația extensiilor se află în specificația extensiilor SOCKS a proiectului și este scurtă. Absența unei comenzi pentru datagrame este intenționată: redirecționarea UDP arbitrar ar da rețelei un rol de redirectare pentru care nu a fost niciodată proiectată.

Acesta este și răspunsul pentru WireGuard, care prin concepție este UDP și nu are alternativă TCP. Nu există o cale acceptată care să direcționeze WireGuard către un port SOCKS, iar orice susține contrariul este un înveliș cu propria poveste despre încredere și întreținere, nu o funcție a vreuneia dintre cele două unelte.

OpenVPN este excepția parțială, pentru că poate fi configurat să tuneleze prin TCP și înțelege o opțiune de proxy SOCKS. Totuși, asta cere un server configurat pentru TCP și o decizie conștientă despre consecințele asupra performanței și a amprentei, deci este o alegere de proiectare, nu o corecție de compatibilitate.

Rulați verificarea în ordine

Confirmați mai întâi că proxy-ul funcționează pentru fluxuri, ca o eșec ulterior să nu fie pus pe seama unui port inaccesibil. Apoi confirmați traficul aplicației înseși și observați ce socketuri deschide de fapt.

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'

O primă comandă reușită și un flux stabilit pe a doua linie arată că traseul prin proxy funcționează conform proiectării. A treia comandă caută socketuri de datagrame locale care aparțin aplicației; dacă clientul deschide unul și trimite direct la o adresă îndepărtată, nu a consultat niciodată proxy-ul și nicio setare de proxy nu va schimba asta. Dacă eșuează deja la primul pas, opriți-vă și reparați traseul prin proxy înainte de a investiga aplicația, pentru că două defecte simultane produc un raport cu care nimeni nu poate acționa.

Reveniți și alegeți unealta potrivită

Eliminați orice variabilă de mediu pentru proxy sau setare de proxy pe aplicație care direcționa clientul UDP către portul SOCKS; lăsarea lor face testele ulterioare ambigue. Restabiliți configurația anterioară dintr-o copie, reporniți aplicația și confirmați că comportamentul original revine, astfel încât comparația să fie curată. O revenire care nu este verificată este doar speranța că starea s-a schimbat.

Pentru un transport care trebuie să rămână UDP, un VPN este de obicei mai potrivit: transportă pachetele aplicației fără a-i cere să vorbească un protocol de proxy, cu prețul unor proprietăți de anonimat complet diferite. Folosiți fiecare unealtă pentru ceea ce documentează și tratați orice punte între ele ca un sistem separat care are nevoie de propria revizuire. Notați în raportul final ce strat transportă ce transport, pentru ca următoarea persoană să nu redescopere aceeași graniță cu altă aplicație.