UDP cez SOCKS port Toru: čo sa neprenáša

Nasmerovanie aplikácie na SOCKS port funguje pri prehliadači a zlyháva pri hre, a dôvodom nie je konfigurácia. SOCKS5 definuje niekoľko príkazov a implementácia môže podporovať iba niektoré z nich; rozhranie Toru prijíma prúdové spojenia a preklad mien, nie ľubovoľné preposielanie datagramov. Klient, ktorý posiela UDP a očakáva, že ho proxy prepošle, žiada príkaz, ktorý server neimplementuje. Nasledujúci postup to overí za niekoľko minút a potom vyberie transport, ktorý skutočne môže fungovať.

Overte, čo aplikácia skutočne odosiela

Začnite určením transportu, nie názvu protokolu. Hlasový klient sa môže prihlásiť cez HTTPS a potom prenášať médiá cez UDP; hra sa môže autentizovať cez TCP a hrať cez UDP; prenos súborov môže používať TCP na riadenie a UDP na zisťovanie. Prvé dve správania vyzerajú rovnako, až kým sa prihlásenie nepodarí a hovor stále zlyháva, preto „pripojilo sa“ nie je dôkazom, že funguje celá aplikácia. Niektorí klienti sa aj sami vracajú z UDP na TCP, čo spôsobuje, že čiastočne fungujúca relácia vyzerá ako nestabilná sieť a nie ako zablokovaný transport.

Zapíšte cieľový port a transport pre časť, ktorá zlyháva. Ten jediný riadok rozhoduje, či proxy vôbec môže pomôcť.

Čo rozhranie SOCKS Toru prijme

Tor implementuje príkaz SOCKS5 CONNECT pre prúdové spojenia a rozširujúce príkazy na preklad mien, preto prehliadač cez neho funguje bez zmeny. UDP ASSOCIATE, príkaz, ktorý by klientovi umožnil odovzdať datagramy proxy na preposlanie, nie je súčasťou toho, čo Tor ponúka. Dokumentácia rozšírení je v špecifikácii rozšírení SOCKS projektu a je krátka. Neprítomnosť príkazu pre datagramy je zámerná: preposielanie ľubovoľného UDP by dalo sieti úlohu preposielača, na ktorú nebola nikdy navrhnutá.

Toto je aj odpoveď pre WireGuard, ktorý je z princípu UDP a nemá záložnú cestu cez TCP. Neexistuje podporovaná cesta, ktorá by WireGuard nasmerovala na SOCKS port, a všetko, čo tvrdí opak, je obal s vlastným príbehom dôvery a údržby, nie funkcia jedného z dvoch nástrojov.

OpenVPN je čiastočnou výnimkou, pretože ho možno nakonfigurovať na tunelovanie cez TCP a rozumie voľbe proxy SOCKS. To však stále vyžaduje server nakonfigurovaný pre TCP a vedomé rozhodnutie o dôsledkoch na výkon a odtlačok, takže je to dizajnová voľba, nie oprava kompatibility.

Vykonajte kontrolu po poradí

Najprv potvrďte, že proxy funguje pre prúdy, aby sa neskoršie zlyhanie nedalo pripísať nedostupnému portu. Potom potvrďte vlastnú prevádzku aplikácie a sledujte, ktoré sockety skutočne otvára.

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'

Úspešný prvý príkaz a nadviazaný prúd v druhom riadku ukazujú, že cesta cez proxy funguje podľa návrhu. Tretí príkaz hľadá lokálne datagramové sockety patriace aplikácii; ak klient jeden otvorí a posiela priamo na vzdialenú adresu, proxy nikdy nekonzultoval a žiadne nastavenie proxy to nezmení. Ak zlyhá už v prvom kroku, zastavte sa a opravte cestu cez proxy, skôr než začnete skúmať aplikáciu, pretože dve poruchy naraz vytvoria správu, s ktorou nikto nemôže nič urobiť.

Vráťte zmeny a vyberte správny nástroj

Odstráňte všetky premenné prostredia proxy alebo nastavenia proxy pre jednotlivé aplikácie, ktoré smerovali klienta UDP na SOCKS port; ich ponechanie robí neskoršie testy nejednoznačnými. Obnovte predchádzajúcu konfiguráciu z kópie, reštartujte aplikáciu a potvrďte, že sa pôvodné správanie vráti, aby bolo porovnanie čisté. Vrátenie, ktoré nie je overené, je len nádejou, že sa stav zmenil.

Pre transport, ktorý musí zostať UDP, je VPN zvyčajne vhodnejšia: prenáša pakety aplikácie bez toho, aby od nej žiadala hovoriť proxy protokolom, za cenu úplne odlišných vlastností anonymity. Každý nástroj používajte na to, čo dokumentuje, a každý most medzi nimi berte ako samostatný systém, ktorý potrebuje vlastné posúdenie. Do záverečnej správy zapíšte, ktorá vrstva nesie ktorý transport, aby ďalší človek neobjavil tú istú hranicu s inou aplikáciou.