VPN läbi Tori: kõigepealt transpordikontroll

Tor-eelne tähendab, et VPN-klient asub SOCKS-puhverserveri taga, seega ehitatakse tunnel ise läbi Tori ja rakenduste liiklus väljub VPN-i lõpp-punktist. See on üks konkreetne järjekord ja see pole see, mida enamik inimesi ehitab. Tor Browseri avamine tavalise VPN-kliendi kõrval ei sunni kumbagi programmi kasutama teise teed.

Minge kontrollidest järjekorras läbi. Igaüks otsustab, kas järgmist tasub alustada.

Millist järjekorda te tegelikult ehitate

Kahte järjekorda aetakse samas vestluses segi. Tor enne tähendab, et VPN-klient jõuab oma serverini SOCKS-puhverserveri kaudu, seega ehitatakse tunnel Tori peale. VPN enne tähendab, et Tori liiklus väljub tunneli kaudu, mida enamik inimesi ehitab kogemata ja kirjeldab seejärel teisena. Esimene koondab edastuspiiri VPN-operaatori juurde, teine koondab selle Tori sisse- ja väljapääsu juurde. Kumbki pole see, mille saate mõlema rakenduse korraga avatuna hoides.

Kirjutage enne millegi seadistamist üles, millist järjekorda ülesanne vajab, sest mõlemad nõuavad erinevaid tarkvaraseadeid ja ebaõnnestuvad erinevates kohtades. Valesti nimetatud järjekord saadab teid tunniks vale kihi tõrkeid otsima. Kõik allpool eeldab Tori enne.

Kontrollige transporti enne kõike muud

Tori SOCKS-liides edastab TCP-vooge ega paku üldist UDP-assotsiatsiooni. VPN, mille transport on UDP, ei saa seda puhverserverit tavalise võrguliidesena käsitleda ja ükski kliendiseade ei muuda seda, mida puhverserver on valmis edasi saatma. WireGuard oma tavalisel kujul on ilmne ohver. OpenVPN-i profiil TCP-režiimis on tavaline lahendus ja sellele tuleb ikkagi selgesõnaliselt öelda, et puhverserverit kasutada.

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

Enne kui hakkate selle kaudu tunnelit siluma, veenduge, et puhverserver kuulab ja suudab kanda ühe lihtsa HTTPS-päringu. Kui lihtne päring ebaõnnestub, ei õnnestu VPN-kliendil kunagi ja selle logid ei ütle teile, miks.

Kirjutage vaatleja kaart ümber

Tori sissepääs näeb allikat, mis Tori poole ühendub, kui miski varasem pole seda muutnud, seega see hüpe õpib teie aadressi. VPN-teenusepakkuja saab Toriga küljelt saabuva ühenduse, kuid võib siiski teada kontot, maksekannet või volitust, mille sa tunneli sees saatsid. VPN-i kaudu jõutud sihtkohad näevad selle väljapääsu, mitte Tori väljapääsu, ja see koondab lõpliku edastuspiiri ühe operaatori juurde.

See ei loo uuesti ka hajutatud teed iga sihtkoha jaoks. Tor Browser ehitab iga saidi jaoks värske vooluringi; Toriga kaetud VPN ehitab ühe tunneli ja iga sait selle taga jagab seda lõpp-punkti. Käsitlege erinevust projekteerimisfaktina, mitte kõrvaldatava piiranguna.

Loendage tõrkekihid, kui see katki läheb

Katkisel seadistusel on vähemalt neli sõltumatut kihti: SOCKS-ühendus, TLS-kätlus VPN-serveriga, VPN-i enda kätlus ja seejärel marsruutimine või nimelahendus tunneli sees. Igaüks ebaõnnestub erineva sümptomiga ja igaüks vajab erinevat parandust. Sertifikaadikontrollide lõdvendamine sellepärast, et tunnel ei tõuse, on klassikaline vale diagnoos ja muudab transpordiprobleemi turbeprobleemiks.

Logige esimene kiht, mis ebaõnnestub, ja lõpetage seal. Puhverserveri keeldumine ja tagasilükatud võti ei ole sama sündmuse variatsioonid.

Lõpetage, kui ohumudel vajab Tor Browseri kaitset

Suvaliste rakenduste marsruutimine Toriga kaetud VPN-i kaudu ei anna neile rakendustele Tor Browseri sõrmejälje- ja isolatsioonifunktsioone. Nende kontod, identifikaatorid ja oma võrgukäitumine jäävad oluliseks ning tunnel ei normaliseeri neist ühtegi. Kui eesmärk on brauser, mis sulandub teiste kasutajate hulka, ei paku see järjekord seda.

Tor Project ise hoiatab kombinatsioonide eest, mida kasutajad ei suuda õigesti seadistada, ja see kehtib enamiku inimeste kohta. See on teadlik disain kitsa ohumudeli jaoks, mitte lühitee kogu seadme anonüümse liikluseni.