VPN do Toru, Tor do VPN: proč se řetěz láme

Skládání VPN, Toru a aplikačního proxy vypadá jako násobení soukromí, a ve skutečnosti násobí počet míst, kde může spojení zemřít. Obvyklým výsledkem je prohlížeč, který se točí, zatímco všechny tři nástroje hlásí, že jsou v pořádku. Změna všech tří nastavení najednou pak odstraní jedinou stopu o tom, který z nich lže.

Nejprve nakreslete zamýšlenou cestu v pořadí a pojmenujte, který program otevírá každé spojení a které jméno se v každém kroku překládá.

Vrstvy se nesčítají, navzájem na sebe působí

VPN před Torem znamená, že vstupní spojení klienta Toru putuje uvnitř tunelu. VPN nesená přes Tor znamená, že vlastní koncový bod klienta VPN musí být dosažitelný přes Tor, což je úplně jiný požadavek. Proxy prohlížeče přidává další skok, o kterém operační systém nic neví. Tři uspořádání, tři samostatné seznamy závislostí.

Každé uspořádání mění, co lze přeložit, co lze přenést a kdo vidí první paket. Jen jedno z nich může být konfigurace, kterou jste mysleli.

Do diagramu přidejte i přímou cestu. Záložní trasa, výjimka rozděleného tunelu nebo obejití proxy mohou stránku načíst, a přitom tiše přeskočit řetěz, který jste chtěli otestovat, a takový úspěch je zavádějící víc než selhání.

Pořadí rozhoduje, co lze přenést

Tor přenáší TCP toky přes své rozhraní SOCKS a klient, který požádá proxy o přeložení názvu hostitele, udrží dotaz uvnitř okruhu. UDP tak v běžných konfiguracích neputuje, proto nelze tunel WireGuard vnořit do Toru bez dalšího TCP relé uprostřed.

OpenVPN lze přinutit k TCP, takže takové uspořádání je alespoň popsatelné. Je také pomalejší a křehčí a způsob selhání při přerušení vypadá stejně jako zablokovaný port. Očekávejte, že rozlišením těchto dvou strávíte více času než opravou kteréhokoli z nich.

Překlad je druhá polovina. S --socks5-hostname proxy překládá cílovou adresu, zatímco prosté --socks5 se nejdřív zeptá místního překladače a jméno unikne mimo okruh. Právě tento jediný přepínač rozhoduje, zda dotaz na jméno patří do řetězu, nebo k vašemu poskytovateli.

Jak najít první porušenou hranici

Testujte fáze v pořadí, kterým putují pakety, neškodnými požadavky, a zastavte se u první, která selže. Poznamenejte si, který příkaz běžel první, protože pořadí je součástí důkazu. Dva příkazy oddělí mrtvý okruh od mrtvého 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

První hlásí, zda se požadavek přes SOCKS proxy vůbec dokončí, a druhý ukazuje adresu, kterou síť právě prezentuje. Pokud první selže a druhý uspěje, problém je u klienta Toru nebo před ním. Pokud uspějí oba a prohlížeč přesto selhává, aplikace používá jinou cestu než shell.

Stránka s veřejnou IP také popisuje jen poslední viditelný výstup. Nemůže říct, kolik skoků mu předcházelo, takže ji spojte s podporovaným stavovým výstupem každého nástroje, místo abyste jedno číslo považovali za diagram.

Kdy přestat přidávat vrstvy

Pokud nedokážete jednou větou říct, co vrstva přináší, odstraňte ji. Řetěz, jehož účel není jasný, je řetěz, který nikdo neodladí ve tři ráno, a zisk soukromí z nevysvětleného skoku bývá menší než dostupnost, kterou ztratíte.

Pokud si vrstva své místo opravdu zaslouží, otestujte ji nejdřív samotnou, pak přidejte další a cestu znovu potvrďte stejnými dvěma příkazy. Před běžným používáním obnovte celý řetěz a nechte ověřování TLS a autentizaci zapnuté; varování certifikátu přijaté kvůli načtení stránky je obchvat směrování, ne oprava. Zapište pořadí, na kterém jste se ustálili, dokud je čerstvé.

Zapište to pořadí včetně překladače, který v každé fázi odpovídá. Fungující řetěz, který umíte popsat, přežije další aktualizaci, kdežto fungující řetěz složený zkoušením s ní zmizí. Přidejte datum a verze, aby šlo pozdější selhání porovnat se známým dobrým stavem, místo aby se o něm hádalo z paměti. Deset řádků v textovém souboru ušetří večer hádání.