VPN do Toru, Tor do VPN: prečo sa reťaz láme

Skladanie VPN, Toru a aplikačného proxy vyzerá ako násobenie súkromia, a v skutočnosti násobí počet miest, kde môže spojenie zomrieť. Zvyčajným výsledkom je prehliadač, ktorý sa točí, kým všetky tri nástroje hlásia, že sú v poriadku. Zmena všetkých troch nastavení naraz potom odstráni jedinú stopu o tom, ktorý z nich klame.

Najprv nakreslite zamýšľanú cestu v poradí a pomenujte, ktorý program otvára každé spojenie a ktoré meno sa v každom kroku prekladá.

Vrstvy sa nesčítavajú, navzájom na seba pôsobia

VPN pred Torom znamená, že vstupné spojenie klienta Toru putuje vnútri tunela. VPN nesená cez Tor znamená, že vlastný koncový bod klienta VPN musí byť dosiahnuteľný cez Tor, čo je úplne iná požiadavka. Proxy prehliadača pridáva ďalší skok, o ktorom operačný systém nič nevie. Tri usporiadania, tri samostatné zoznamy závislostí.

Každé usporiadanie mení, čo sa dá preložiť, čo sa dá preniesť a kto vidí prvý paket. Len jedno z nich môže byť konfigurácia, ktorú ste mysleli.

Do diagramu pridajte aj priamu cestu. Záložná trasa, výnimka rozdeleného tunela alebo obídenie proxy môžu stránku načítať a pritom potichu preskočiť reťaz, ktorú ste chceli otestovať, a taký úspech zavádza viac ako zlyhanie.

Poradie rozhoduje, čo sa dá preniesť

Tor prenáša TCP toky cez svoje rozhranie SOCKS a klient, ktorý požiada proxy o preklad názvu hostiteľa, udrží dopyt vnútri okruhu. UDP tak v bežných konfiguráciách neputuje, preto sa tunel WireGuard nedá vnoriť do Toru bez ďalšieho TCP relé uprostred.

OpenVPN sa dá prinútiť na TCP, takže to usporiadanie je aspoň opísateľné. Je tiež pomalšie a krehkejšie a spôsob zlyhania pri prerušení vyzerá rovnako ako zablokovaný port. Očakávajte, že rozlíšením týchto dvoch strávite viac času než opravou ktoréhokoľvek z nich.

Preklad je druhá polovica. S --socks5-hostname proxy prekladá cieľovú adresu, zatiaľ čo prosté --socks5 sa najprv opýta miestneho prekladača a meno unikne mimo okruhu. Práve tento jediný prepínač rozhoduje, či dopyt na meno patrí do reťaze, alebo k vášmu poskytovateľovi.

Ako nájsť prvú porušenú hranicu

Testujte fázy v poradí, ktorým putujú pakety, neškodnými požiadavkami, a zastavte sa pri prvej, ktorá zlyhá. Poznamenajte si, ktorý príkaz bežal prvý, pretože poradie je súčasťou dôkazu. Dva príkazy oddelia mŕtvy okruh od mŕtveho výstupu:

curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip
curl -4 -s https://api.ipify.org; echo

Prvý hlási, či sa požiadavka cez SOCKS proxy vôbec dokončí, a druhý ukazuje adresu, ktorú sieť práve prezentuje. Ak prvý zlyhá a druhý uspeje, problém je pri klientovi Toru alebo pred ním. Ak uspejú oba a prehliadač napriek tomu zlyháva, aplikácia používa inú cestu než shell.

Stránka s verejnou IP tiež opisuje len posledný viditeľný výstup. Nemôže povedať, koľko skokov mu predchádzalo, takže ju spojte s podporovaným stavovým výstupom každého nástroja, namiesto toho, aby ste jedno číslo považovali za diagram.

Kedy prestať pridávať vrstvy

Ak nedokážete jednou vetou povedať, čo vrstva prináša, odstráňte ju. Reťaz, ktorej účel nie je jasný, je reťaz, ktorú nikto neodladí o tretej ráno, a zisk súkromia z nevysvetleného skoku je zvyčajne menší než dostupnosť, ktorú stratíte.

Ak si vrstva svoje miesto naozaj zaslúži, otestujte ju najprv samotnú, potom pridajte ďalšiu a cestu znova potvrďte tými istými dvoma príkazmi. Pred bežným používaním obnovte celú reťaz a nechajte overovanie TLS a autentifikáciu zapnuté; varovanie o certifikáte prijaté kvôli načítaniu stránky je obchádzanie smerovania, nie oprava. Zapíšte si poradie, na ktorom ste sa ustálili, kým je ešte čerstvé.

Zapíšte to poradie vrátane prekladača, ktorý v každej fáze odpovedá. Fungujúca reťaz, ktorú viete opísať, prežije ďalšiu aktualizáciu, kým fungujúca reťaz zložená skúšaním s ňou zmizne. Pridajte dátum a verzie, aby sa neskoršie zlyhanie dalo porovnať so známym dobrým stavom namiesto hádania sa o ňom z pamäti. Desať riadkov v textovom súbore ušetrí večer hádania.