VPN enne Torit: mida järjekord tegelikult muudab
VPN-iga alustav tee muudab, kes näeb sinu lähteaadressi ja kes näeb Tori liiklust, ning lisab ühe usalduse. Enne kasu eeldamist tee tee- ja tõrkekontrollid.
VPN-i esimesena ühendamine loob kindla ahela: seade, VPN-i lõpp-punkt, Tori sissepääs, Tori vooluahel, sihtkoht. Sinu kohalik võrk näeb ühte krüpteeritud ühendust VPN-iga ja Tori sissepääsusõlm näeb VPN-i väljundit otsese allikana sinu teenusepakkuja aadressi asemel. VPN-i operaator näeb omakorda ühendusi Tori sissepääsu taristu poole ja võib sihtkohtadest Tori kasutust järeldada. Iga vaatleja kaotab midagi ja võidab midagi, seepärast on järjekord vahetus, mitte uuendus.
Miski selles ahelas ei muuda seda, mida veebisait õpib sinu kontolt, küpsistest või sisestatud andmetest.
Mida järjekord muudab
Kohalik võrk ja ISP kaotavad otsese nähtavuse sinu Tori liiklusele, sest esimene hüpe on nüüd krüpteeritud tunnel teenusepakkujani. Tori sissepääsuvalvur kaotab sinu koduaadressi ja näeb VPN-i väljundit. VPN-i teenusepakkuja saab metaandmed, mida varem hoidis sinu ISP: milliseid aadresse sa kontakteerid, mis aegadel ja kui palju andmeid liigub.
Pärast sissepääsuvalvurit käitub vooluahel nagu enne. Releed eraldavad endiselt sissepääsu, keskosa ja väljundi rollid ning VPN ei näe lõplikku sisu rohkem kui sinu ISP seda nägi.
Kinnita tee, mida tegelikult kasutatakse
Jagatud tunnelimine on tavaline põhjus, miks kavandatud ahel ei ole tegelik.Kui Tor Browser on tunnelist välja jäetud, või teine profiil suunab teisiti, näeb sissepääsuvalvur jälle teenusepakkuja aadressi, samal ajal kui liides näeb endiselt ühendatud. Kontrolli marsruuti ja vaadeldud väljundit, mitte ikooni.
ip route get 1.1.1.1 ss -tunp | grep -E 'tor|9150|9050' curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip resolvectl status | grep -A3 'DNS Servers'
SOCKS-i päringule pordi 9150 kaudu vastab Tor Browseri enda klient, seega IsTor true vastus kinnitab brauseri vooluahelat, mitte seda, et iga teine rakendus seda kasutab. Resolveri väljundit tasub salvestada, sest DNS võib väljuda teel, mida tunnel ei kata. Hoia mõlemad väljundid ajatempliga. Need on järgmise võrdluse alus.
Võrdle seda otsese päringuga tavalisest terminalist: kui ka see teatab Torist, suunab midagi muud liiklust ümber ja ahel ei ole see, mida disain eeldas.
Jälgi, mis juhtub, kui tunnel katkeb
Klient, mis langeb vaikselt tagasi kohalikule liidesele, muudab allikat, mida sissepääsuvalvur näeb, ja kasutaja ei tea seda tavaliselt, sest leht laaditakse endiselt. Just see tõrge on testimist väärt, mitte õnnelik tee. Ühenda tunnel meelega lahti ja jälgi, kas Tori liiklus peatub või jätkub kaitseta.
nft list ruleset | grep -i -E 'vpn|tun|drop' iptables -S | grep -i tun ip link show | grep -E 'tun|wg'
Tulemüüri reeglid, mis blokeerivad tunnelist väljapoole suunduvat liiklust, on ainus usaldusväärne varukontroll ja need peavad katma nii brauseri SOCKS-kliendi kui ka iga muu rakenduse, mis sulle oluline on. Brauseri laiendus ei ole seadme VPN ega mõjuta teisi programme ega väliseid vaatlejaid.
Otsusta, kas lisakiht on oma usaldust väärt
Tor Project soovitab mitte virnastada VPN-i Tori alla, kui sa ei suuda seadistust ise hinnata. Nende nimetatud põhjus on lisasõltuvus: veel üks osapool, veel üks konto ja veel üks tõrkerežiim. Kui eesmärk on takistada ISP-l näha, et kasutad Torit, tegeleb VPN just selle vaatlejaga. Kui eesmärk on tugevam anonüümsus globaalse vaatleja vastu, siis VPN seda ei paku.
Olemas on ka vastupidine järjekord ja nimed ei ole vahetatavad:Tor üle VPN-i ja VPN üle Tori kirjeldavad erinevaid usaldussuhteid ja erinevat tõrkekäitumist. Loe võrdlust enne nende segamist.
Kirjuta üles, millist vaatlejat sa nihutada tahad, seejärel kontrolli, et tegelik tee vastab disainile, seejärel kontrolli tõrkekäitumist. Kui need kolm vastust ei õigusta lisakontot ja -seadistust, on dokumenteeritud Tor Browseri seadistuses vähem osi, mida saab valesti teha.