VPN přes Tor: nejdřív kontrola transportu

Tor nejdřív znamená, že klient VPN sedí za proxy SOCKS, takže tunel sám se staví přes Tor a provoz aplikací vychází z koncového bodu VPN. To je jedno konkrétní pořadí a není to to, co většina lidí staví. Otevření Tor Browseru vedle běžného klienta VPN nenutí ani jeden z obou programů používat cestu toho druhého.

Projděte kontroly popořadě. Každá rozhoduje, zda má smysl začínat další.

Jaké pořadí vlastně stavíte

Dvě pořadí se v jedné konverzaci pletou. Tor nejdřív znamená, že klient VPN dosáhne svého serveru přes proxy SOCKS, takže tunel se staví nad Torem. VPN nejdřív znamená, že provoz Toru vychází tunelem, což většina lidí postaví omylem a pak to popisuje jako to druhé. První soustředí hranici předávání u operátora VPN, druhé ji soustředí u vstupu a výstupu Toru. Ani jedno není to, co získáte tím, že máte obě aplikace otevřené zároveň.

Než cokoli nakonfigurujete, zapište si, které pořadí úkol potřebuje, protože obě vyžadují jiná softwarová nastavení a selhávají na jiných místech. Špatně označené pořadí vás pošle hodinu ladit špatnou vrstvu. Vše níže předpokládá Tor nejdřív.

Zkontrolujte transport dřív než cokoli jiného

Rozhraní SOCKS v Toru přenáší TCP toky a neposkytuje obecnou asociaci UDP. VPN, jejíž transport je UDP, nemůže s tímto proxy zacházet jako s běžným síťovým rozhraním a žádné nastavení klienta nemění, co je proxy ochotna předat. WireGuard ve své obvyklé podobě je zjevná oběť. Profil OpenVPN v režimu TCP je obvyklé řešení a stále mu musí být výslovně řečeno, aby proxy použil.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

Než začnete tunelem přes proxy ladit, ověřte, že proxy naslouchá a unese jeden prostý požadavek HTTPS. Pokud prostý požadavek selže, klient VPN nikdy neuspěje a jeho protokoly vám neřeknou proč.

Přepište mapu pozorovatele

Vstup Toru může vidět zdroj, který se připojuje k Toru, pokud to něco dřívějšího nezměnilo, takže ten skok pozná vaši adresu. Poskytovatel VPN přijímá spojení přicházející ze strany Toru, ale stále může znát účet, platební záznam nebo přihlašovací údaj, který jste poslali uvnitř tunelu. Cíle dosažené přes VPN vidí její výstup, ne výstup Toru, a to soustředí konečnou hranici předávání u jednoho operátora.

Také nevytváří distribuovanou cestu ke každému cíli. Tor Browser staví čerstvý okruh pro každý web; VPN nesená přes Tor staví jeden tunel a každý web za ním sdílí tento koncový bod. Berte rozdíl jako fakt návrhu, ne jako omezení, které je třeba vyladit pryč.

Spočítejte vrstvy selhání, když se to rozbije

Rozbité nastavení má nejméně čtyři nezávislé vrstvy: spojení SOCKS, TLS handshake se serverem VPN, samotný handshake VPN a pak směrování nebo překlad jmen uvnitř tunelu. Každá selhává s jiným příznakem a každá potřebuje jinou opravu. Povolení kontrol certifikátů proto, že tunel nenaběhne, je klasická chybná diagnóza a mění problém transportu na problém bezpečnosti.

Zaznamenejte první vrstvu, která selže, a tam přestaňte. Odmítnutí proxy a odmítnutý klíč nejsou variantami téže události.

Přestaňte, pokud model hrozeb potřebuje obrany Tor Browseru

Směrování libovolných aplikací přes VPN nesenou Torem nedává těmto aplikacím funkce otisku a izolace Tor Browseru. Jejich účty, identifikátory a vlastní síťové chování zůstávají relevantní a tunel nic z toho normalizuje. Pokud je cílem prohlížeč, který splývá s ostatními uživateli, toto pořadí ho nedodá.

Sám Tor Project varuje před kombinacemi, které uživatelé nedokážou správně nastavit, a tahle platí pro většinu lidí. Je to záměrný návrh pro úzký model hrozeb, ne zkratka k anonymnímu provozu celého zařízení.