VPN prek Tora: najprej preverjanje prenosa

Tor najprej pomeni, da odjemalec VPN sedi za posrednikom SOCKS, zato se tunel sam zgradi prek Tora in promet aplikacij izhaja iz končne točke VPN. To je en določen vrstni red in ni tisto, kar gradi večina ljudi. Odpiranje Tor Browserja ob običajnem odjemalcu VPN ne prisili nobenega od obeh programov, da uporablja pot drugega.

Pojdite skozi preverjanja po vrsti. Vsako odloči, ali se je naslednje vredno začeti.

Kateri vrstni red pravzaprav gradite

Dva vrstna reda se zamenjujeta v istem pogovoru. Tor najprej pomeni, da odjemalec VPN doseže svoj strežnik prek posrednika SOCKS, zato se tunel zgradi nad Torom. VPN najprej pomeni, da promet Tora izhaja skozi tunel, kar večina ljudi zgradi po naključju in nato opiše kot drugega. Prvi usmeri mejo posredovanja k operaterju VPN, drugi jo usmeri k vhodu in izhodu Tora. Noben ni tisto, kar dobite, če imate obe aplikaciji odprti hkrati.

Preden karkoli konfigurirate, zapišite, kateri vrstni red naloga potrebuje, ker oba zahtevata drugačne programske nastavitve in odpovedujeta na različnih mestih. Napačno označen vrstni red vas pošlje za eno uro iskat napako v napačno plast. Vse spodaj predpostavlja Tor najprej.

Preverite prenos pred vsem drugim

Vmesnik SOCKS v Toru prenaša tokove TCP in ne zagotavlja splošne povezave UDP. VPN, katerega prenos je UDP, tega posrednika ne more obravnavati kot običajen omrežni vmesnik, in nobena nastavitev odjemalca ne spremeni, kaj je posrednik pripravljen posredovati. WireGuard v svoji običajni obliki je očitna žrtev. Profil OpenVPN v načinu TCP je običajna rešitev in tudi njemu je treba izrecno povedati, naj uporabi posrednika.

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

Preden odpravljate napake v tunelu skozi njega, potrdite, da posrednik posluša in lahko prenese eno običajno zahtevo HTTPS. Če običajna zahteva spodleti, odjemalec VPN ne bo nikoli uspel in njegovi dnevniki vam ne bodo povedali, zakaj.

Prepišite zemljevid opazovalca

Vhod Tora lahko vidi vir, ki se poveže s Torom, razen če ga je kaj zgodnejšega spremenilo, zato ta skok izve vaš naslov. Ponudnik VPN prejme povezavo, ki pride s strani Tora, a lahko še vedno pozna račun, plačilni zapis ali poverilnico, ki ste jo poslali znotraj tunela. Cilji, doseženi prek VPN, vidijo njegov izhod in ne izhoda Tora, to pa usmeri končno mejo posredovanja k enemu operaterju.

Prav tako ne ustvari znova porazdeljene poti do vsakega cilja. Tor Browser zgradi sveže vezje za vsako spletno mesto; VPN, nošen prek Tora, zgradi en tunel in vsako spletno mesto za njim si deli to končno točko. Razliko obravnavajte kot dejstvo oblikovanja in ne kot omejitev, ki jo je treba odpraviti.

Preštejte plasti odpovedi, ko se zlomi

Pokvarjena nastavitev ima vsaj štiri neodvisne plasti: povezavo SOCKS, rokovanje TLS s strežnikom VPN, samo rokovanje VPN in nato usmerjanje ali razreševanje imen znotraj tunela. Vsaka odpove z drugačnim simptomom in vsaka potrebuje drugačno popravilo. Popuščanje preverjanj potrdil, ker se tunel ne dvigne, je klasična napačna diagnoza in spremeni težavo prenosa v varnostno težavo.

Zabeležite prvo plast, ki odpove, in se tam ustavite. Zavrnitev posrednika in zavrnjen ključ nista različici istega dogodka.

Ustavite se, če model grožnje potrebuje obrambo Tor Browserja

Usmerjanje poljubnih aplikacij skozi VPN, ki ga nosi Tor, tem aplikacijam ne daje funkcij prstnega odtisa in izolacije Tor Browserja. Njihovi računi, identifikatorji in lastno omrežno vedenje ostajajo pomembni, tunel pa nobenega od tega ne normalizira. Če je cilj brskalnik, ki se zlije z drugimi uporabniki, ta vrstni red tega ne zagotavlja.

Tor Project sam opozarja pred kombinacijami, ki jih uporabniki ne znajo pravilno nastaviti, in ta velja za večino ljudi. To je namerno oblikovanje za ozek model groženj, ne bližnjica do anonimnega prometa celotne naprave.