VPN caur Tor: vispirms transporta pārbaude

Tor vispirms nozīmē, ka VPN klients sēž aiz SOCKS starpniekservera, tāpēc pats tunelis tiek būvēts caur Tor un lietotņu trafiks iziet no VPN galapunkta. Tā ir viena konkrēta secība, un tas nav tas, ko būvē lielākā daļa cilvēku. Tor Browser atvēršana blakus parastam VPN klientam neliek nevienai no divām programmām izmantot otras ceļu.

Izejiet pārbaudes secībā. Katra izlemj, vai nākamo ir vērts sākt.

Kādu secību jūs patiesībā būvējat

Divas secības tiek sajauktas vienā sarunā. Tor vispirms nozīmē, ka VPN klients sasniedz savu serveri caur SOCKS starpniekserveri, tāpēc tunelis tiek būvēts virs Tor. VPN vispirms nozīmē, ka Tor trafiks iziet caur tuneli, ko lielākā daļa cilvēku būvē nejauši un pēc tam apraksta kā otru. Pirmā koncentrē pārsūtīšanas robežu pie VPN operatora, otrā koncentrē to pie Tor ieejas un izejas. Neviena nav tas, ko iegūstat, turot abas lietotnes vienlaikus atvērtas.

Pirms kaut ko konfigurējat, pierakstiet, kāda secība uzdevumam nepieciešama, jo abas prasa atšķirīgus programmatūras iestatījumus un neizdodas dažādās vietās. Nepareizi nosaukta secība aizsūta jūs stundu meklēt kļūdu nepareizajā slānī. Viss zemāk pieņem Tor vispirms.

Pārbaudiet transportu pirms visa cita

Tor SOCKS saskarne pārsūta TCP plūsmas un nenodrošina vispārīgu UDP asociāciju. VPN, kura transports ir UDP, nevar šo starpniekserveri uzskatīt par parastu tīkla saskarni, un neviens klienta iestatījums nemaina to, ko starpniekserveris ir gatavs pārsūtīt. WireGuard tā parastajā formā ir acīmredzams upuris. OpenVPN profils TCP režīmā ir parastais risinājums, un tam joprojām skaidri jāpasaka izmantot starpniekserveri.

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

Pirms atkļūdojat tuneli caur to, pārliecinieties, ka starpniekserveris klausās un spēj pārsūtīt vienu vienkāršu HTTPS pieprasījumu. Ja vienkāršais pieprasījums neizdodas, VPN klients nekad neizdosies, un tā žurnāli jums nepateiks kāpēc.

Pārrakstiet novērotāja karti

Tor ieeja var redzēt avotu, kas pieslēdzas Tor, ja vien kaut kas agrāks to nav mainījis, tāpēc šis lēciens uzzina jūsu adresi. VPN pakalpojumu sniedzējs saņem savienojumu, kas nāk no Tor puses, bet joprojām var zināt kontu, maksājuma ierakstu vai akreditācijas datus, ko nosūtījāt tuneļa iekšienē. Galamērķi, kas sasniegti caur VPN, redz tā izeju, nevis Tor izeju, un tas koncentrē galīgo pārsūtīšanas robežu pie viena operatora.

Tas arī neatjauno sadalītu ceļu uz katru galamērķi. Tor Browser katram lietojumam būvē jaunu ķēdi; VPN, kas nests caur Tor, būvē vienu tuneli, un katra vietne aiz tā dala šo galapunktu. Uztveriet atšķirību kā dizaina faktu, nevis kā ierobežojumu, kas jānovērš.

Saskaitiet kļūmes slāņus, kad tas salūzt

Salūzušā konfigurācijā ir vismaz četri neatkarīgi slāņi: SOCKS savienojums, TLS rokasspiediens ar VPN serveri, pats VPN rokasspiediens un pēc tam maršrutēšana vai vārdu atrisināšana tuneļa iekšienē. Katrs neizdodas ar atšķirīgu simptomu, un katram vajadzīgs atšķirīgs remonts. Sertifikātu pārbaužu vājināšana tāpēc, ka tunelis neceļas, ir klasiskā nepareizā diagnoze, un tā transporta problēmu pārvērš drošības problēmā.

Reģistrējiet pirmo slāni, kas neizdodas, un apstājieties tur. Starpniekservera atteikums un noraidīta atslēga nav viena notikuma varianti.

Apstājieties, ja draudu modelim vajadzīgas Tor Browser aizsardzības

Patvaļīgu lietotņu maršrutēšana caur VPN, ko nes Tor, nedod šīm lietotnēm Tor Browser pirkstu nospiedumu un izolācijas funkcijas. To konti, identifikatori un pašu tīkla uzvedība joprojām ir svarīgi, un tunelis nevienu no tiem nenormalizē. Ja mērķis ir pārlūks, kas saplūst ar citiem lietotājiem, šī secība to nesniedz.

Pats Tor Project brīdina par kombinācijām, ko lietotāji nevar pareizi konfigurēt, un šī attiecas uz lielāko daļu. Tas ir apzināts dizains šauram draudu modelim, nevis īsceļš uz visas ierīces anonīmu trafiku.