VPN per Tor: pirmiausia transporto patikra

Tor pirmiausia reiškia, kad VPN klientas sėdi už SOCKS tarpinio serverio, todėl tunelis statomas per Tor, o programų srautas išeina iš VPN galinio taško. Tai viena konkreti tvarka, ir tai nėra tai, ką stato dauguma žmonių. Tor Browser atidarymas šalia įprasto VPN kliento nepriverčia nė vienos iš dviejų programų naudoti kitos kelią.

Atlikite patikras iš eilės. Kiekviena nusprendžia, ar verta pradėti kitą.

Kokią tvarką jūs iš tikrųjų statote

Dvi tvarkos painiojamos tame pačiame pokalbyje. Tor pirmiausia reiškia, kad VPN klientas pasiekia savo serverį per SOCKS tarpinį serverį, todėl tunelis statomas ant Tor. VPN pirmiausia reiškia, kad Tor srautas išeina per tunelį, ką dauguma žmonių stato netyčia ir paskui apibūdina kaip kitą. Pirmoji sutelkia perdavimo ribą pas VPN operatorių, antroji ją sutelkia ties Tor įėjimu ir išėjimu. Nė viena nėra tai, ką gaunate laikydami abi programas atidarytas vienu metu.

Užsirašykite, kokios tvarkos reikia užduočiai, prieš ką nors konfigūruodami, nes abi reikalauja skirtingų programinės įrangos nustatymų ir nepavyksta skirtingose vietose. Neteisingai pavadinta tvarka pasiunčia jus valandai ieškoti gedimo netinkamame sluoksnyje. Viskas žemiau daro prielaidą, kad Tor pirmiausia.

Patikrinkite transportą prieš visa kita

Tor SOCKS sąsaja perduoda TCP srautus ir neteikia bendros UDP asociacijos. VPN, kurio transportas yra UDP, negali to tarpinio serverio traktuoti kaip įprastos tinklo sąsajos, ir joks kliento nustatymas nepakeičia to, ką tarpinis serveris yra pasirengęs perduoti. WireGuard įprasta forma yra akivaizdi auka. OpenVPN profilis TCP režimu yra įprastas sprendimas, ir jam vis tiek reikia aiškiai pasakyti naudoti tarpinį serverį.

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

Prieš derindami tunelį per jį, patvirtinkite, kad tarpinis serveris klausosi ir gali perduoti vieną paprastą HTTPS užklausą. Jei paprasta užklausa nepavyksta, VPN klientas niekada nepasiseks, o jo žurnalai nepasakys kodėl.

Perrašykite stebėtojo žemėlapį

Tor įėjimas gali matyti šaltinį, kuris jungiasi prie Tor, nebent kažkas ankstesnio jį pakeitė, todėl tas šuolis sužino jūsų adresą. VPN teikėjas gauna ryšį, ateinantį iš Tor pusės, bet vis tiek gali žinoti paskyrą, mokėjimo įrašą ar kredencialus, kuriuos nusiuntėte tunelio viduje. Tikslai, pasiekiami per VPN, mato jo išėjimą, o ne Tor išėjimą, ir tai sutelkia galutinę perdavimo ribą pas vieną operatorių.

Jis taip pat neatkuria paskirstyto kelio į kiekvieną tikslą. Tor Browser kiekvienai svetainei stato naują grandinę; VPN, nešamas per Tor, stato vieną tunelį, ir kiekviena svetainė už jo dalijasi tuo galiniu tašku. Skirtumą traktuokite kaip dizaino faktą, o ne kaip apribojimą, kurį reikia pašalinti.

Suskaičiuokite gedimo sluoksnius, kai jis lūžta

Sugedusi sąranka turi bent keturis nepriklausomus sluoksnius: SOCKS ryšį, TLS rankos paspaudimą su VPN serveriu, patį VPN rankos paspaudimą ir tada maršrutizavimą ar vardų sprendimą tunelio viduje. Kiekvienas nepavyksta su skirtingu simptomu ir kiekvienam reikia skirtingo remonto. Sertifikatų patikrų susilpninimas dėl to, kad tunelis nekeliasi, yra klasikinė klaidinga diagnostika, ir ji transporto problemą paverčia saugumo problema.

Užregistruokite pirmą nepavykusį sluoksnį ir sustokite ten. Tarpinio serverio atsisakymas ir atmestas raktas nėra to paties įvykio variantai.

Sustokite, jei grėsmės modeliui reikia Tor Browser apsaugų

Savavališkų programų maršrutizavimas per VPN, nešamą Tor, nesuteikia toms programoms Tor Browser pirštų atspaudų ir izoliacijos funkcijų. Jų paskyros, identifikatoriai ir jų pačių tinklo elgsena lieka svarbūs, ir tunelis nė vieno iš jų nenormalizuoja. Jei tikslas yra naršyklė, kuri susilieja su kitais naudotojais, ši tvarka to nesuteikia.

Pats Tor Project įspėja prieš derinius, kurių naudotojai negali tinkamai sukonfigūruoti, ir šis galioja daugumai. Tai sąmoningas dizainas siauram grėsmės modeliui, o ne trumpas kelias į anoniminį viso įrenginio srautą.