UDP přes SOCKS port Toru: co se nepřenáší

Nasměrování aplikace na SOCKS port funguje u prohlížeče a selhává u hry, a důvodem není konfigurace. SOCKS5 definuje několik příkazů a implementace může podporovat jen některé z nich; rozhraní Toru přijímá proudová spojení a překlad jmen, ne libovolné předávání datagramů. Klient, který posílá UDP a očekává, že je proxy přepošle, žádá příkaz, který server neimplementuje. Následující postup to během několika minut ověří a poté vybere transport, který skutečně může fungovat.

Ověřte, co aplikace skutečně odesílá

Začněte určením transportu, nikoli názvu protokolu. Hlasový klient se může přihlásit přes HTTPS a poté přenášet média přes UDP; hra se může autentizovat přes TCP a hrát přes UDP; přenos souborů může používat TCP pro řízení a UDP pro zjišťování. První dvě chování vypadají stejně, dokud přihlášení neuspěje a hovor stále selhává, a proto „připojilo se“ není důkazem, že celá aplikace funguje. Někteří klienti se také sami vracejí z UDP na TCP, což způsobuje, že částečně funkční relace vypadá jako nestabilní síť, a ne jako zablokovaný transport.

Zapište cílový port a transport pro část, která selhává. Ten jediný řádek rozhoduje, zda proxy vůbec může pomoci.

Co rozhraní SOCKS Toru přijme

Tor implementuje příkaz SOCKS5 CONNECT pro proudová spojení a rozšiřující příkazy pro překlad jmen, a proto prohlížeč přes něj funguje beze změny. UDP ASSOCIATE, příkaz, který by klientovi umožnil předat datagramy proxy k předání dál, není součástí toho, co Tor nabízí. Dokumentace rozšíření je v specifikaci rozšíření SOCKS projektu a je krátká. Nepřítomnost příkazu pro datagramy je záměrná: předávání libovolného UDP by síti dalo roli přeposílatele, pro kterou nebyla nikdy navržena.

To je také odpověď pro WireGuard, který je z principu UDP a nemá záložní cestu přes TCP. Neexistuje podporovaná cesta, která by WireGuard nasměrovala na SOCKS port, a vše, co tvrdí opak, je obal s vlastním příběhem důvěry a údržby, nikoli funkce kteréhokoli z obou nástrojů.

OpenVPN je částečnou výjimkou, protože jej lze nakonfigurovat k tunelování přes TCP a rozumí volbě SOCKS proxy. To však stále vyžaduje server nakonfigurovaný pro TCP a vědomé rozhodnutí o důsledcích pro výkon a fingerprint, takže je to designová volba, nikoli oprava kompatibility.

Proveďte kontrolu popořadě

Nejprve potvrďte, že proxy funguje pro proudy, aby pozdější selhání nešlo připsat nedostupnému portu. Poté potvrďte vlastní provoz aplikace a sledujte, které sockety skutečně otevírá.

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'

Úspěšný první příkaz a navázaný proud ve druhém řádku ukazují, že cesta přes proxy funguje podle návrhu. Třetí příkaz hledá místní datagramové sockety patřící aplikaci; pokud klient nějaký otevře a posílá přímo na vzdálenou adresu, proxy nikdy nekonzultoval a žádné nastavení proxy to nezmění. Pokud selže už v prvním kroku, zastavte se a opravte cestu přes proxy, než začnete zkoumat aplikaci, protože dvě závady najednou vytvoří zprávu, se kterou nikdo nemůže nic dělat.

Vraťte změny a vyberte správný nástroj

Odstraňte všechny proměnné prostředí proxy nebo nastavení proxy pro jednotlivé aplikace, které směrovaly klienta UDP na SOCKS port; jejich ponechání činí pozdější testy nejednoznačnými. Obnovte předchozí konfiguraci z kopie, restartujte aplikaci a potvrďte, že se původní chování vrátilo, aby bylo srovnání čisté. Vrácení, které není ověřené, je jen naděje, že se stav změnil.

Pro transport, který musí zůstat UDP, je VPN obvykle vhodnější: přenáší pakety aplikace, aniž by po ní chtěla, aby mluvila proxy protokolem, a to za cenu zcela odlišných vlastností anonymity. Používejte každý nástroj na to, co dokumentuje, a každý most mezi nimi berte jako samostatný systém, který potřebuje vlastní posouzení. Do závěrečné zprávy zapište, která vrstva nese který transport, aby další člověk neobjevoval stejnou hranici s jinou aplikací.