UDP skozi vrata SOCKS Tor: kaj ne gre skozi

Usmerjanje aplikacije na vrata SOCKS deluje pri brskalniku in ne uspe pri igri, razlog pa ni konfiguracija. SOCKS5 določa več ukazov in izvedba lahko podpira le nekatere od njih; vmesnik Tor sprejema tokove povezave in razreševanje imen, ne poljubnega posredovanja datagramov. Odjemalec, ki pošilja UDP in pričakuje, da bo proxy to posredoval, zahteva ukaz, ki ga strežnik ne izvaja. Spodnji vodnik to preveri v nekaj minutah in nato izbere transport, ki lahko resnično deluje.

Preverite, kaj aplikacija v resnici pošilja

Začnite s prepoznavanjem transporta, ne imena protokola. Glasovni odjemalec se lahko prijavi prek HTTPS in nato prenaša medije prek UDP; igra se lahko overi prek TCP in igra prek UDP; prenos datotek lahko uporablja TCP za nadzor in UDP za odkrivanje. Prva dva vedenja sta videti enaka, dokler prijava ne uspe in klic še vedno ne uspe, zato „povezalo se je“ ni dokaz, da deluje cela aplikacija. Nekateri odjemalci se sami vrnejo z UDP na TCP, zaradi česar je delno delujoča seja videti kot nestabilno omrežje in ne kot blokiran transport.

Zapišite ciljna vrata in transport za del, ki ne uspe. Ta ena vrstica odloči, ali lahko proxy sploh pomaga.

Kaj bo vmesnik SOCKS Tor sprejel

Tor izvaja ukaz SOCKS5 CONNECT za tokove povezave in razširitvene ukaze za razreševanje imen, zato brskalnik skozenj deluje nespremenjen. UDP ASSOCIATE, ukaz, ki bi odjemalcu omogočil, da datagrame izroči proxyju za posredovanje, ni del tega, kar Tor ponuja. Dokumentacija razširitev je v specifikaciji razširitev SOCKS projekta in je kratka. Odsotnost ukaza za datagrame je namerna: posredovanje poljubnega UDP bi omrežju dalo vlogo posrednika, za katero ni bilo nikoli zasnovano.

To je tudi odgovor za WireGuard, ki je po zasnovi UDP in nima rezervne poti prek TCP. Ni podprte poti, ki bi WireGuard usmerila na vrata SOCKS, in vse, kar trdi nasprotno, je ovoj z lastno zgodbo o zaupanju in vzdrževanju, ne pa funkcija enega od dveh orodij.

OpenVPN je delna izjema, ker ga je mogoče nastaviti za tuneliranje prek TCP in razume možnost proxyja SOCKS. To še vedno zahteva strežnik, nastavljen za TCP, in zavestno odločitev o posledicah za zmogljivost in prstni odtis, zato je to oblikovalska izbira in ne popravek združljivosti.

Izvedite preverjanje po vrsti

Najprej potrdite, da proxy deluje za tokove, da kasnejše neuspeha ne bi pripisali nedosegljivim vratom. Nato potrdite promet same aplikacije in opazujte, katere vtičnice v resnici odpira.

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'

Uspešen prvi ukaz in vzpostavljen tok v drugi vrstici kažeta, da pot prek proxyja deluje, kot je zasnovano. Tretji ukaz išče lokalne vtičnice datagramov, ki pripadajo aplikaciji; če odjemalec eno odpre in pošilja neposredno na oddaljeni naslov, proxyja nikoli ni vprašal in nobena nastavitev proxyja tega ne bo spremenila. Če ne uspe že v prvem koraku, se ustavite in popravite pot prek proxyja, preden raziskujete aplikacijo, ker dve napaki hkrati dasta poročilo, s katerim nihče ne more ničesar storiti.

Vrnite spremembe in izberite pravo orodje

Odstranite vse okoljske spremenljivke proxyja ali nastavitve proxyja za posamezno aplikacijo, ki so usmerjale odjemalca UDP na vrata SOCKS; če jih pustite, postanejo poznejši testi dvoumni. Obnovite prejšnjo konfiguracijo iz kopije, znova zaženite aplikacijo in potrdite, da se prvotno vedenje vrne, da bo primerjava čista. Vrnitev, ki ni preverjena, je le upanje, da se je stanje spremenilo.

Za transport, ki mora ostati UDP, je VPN običajno primernejši: prenaša pakete aplikacije, ne da bi od nje zahteval, da govori proxy protokol, za ceno povsem drugačnih lastnosti anonimnosti. Vsako orodje uporabite za to, kar dokumentira, in vsak most med njimi obravnavajte kot ločen sistem, ki potrebuje lasten pregled. V končnem poročilu zapišite, kateri sloj prenaša kateri transport, da naslednja oseba ne bo znova odkrila iste meje z drugo aplikacijo.