VPN gjennom Tor: transportkontrollen kjem først

Tor-først tyder at VPN-klienten sit bak ein SOCKS-proxy, slik at tunnelen sjølv blir bygd gjennom Tor og applikasjonstrafikk går ut frå VPN-endepunktet. Det er éin bestemt rekkjefølgje, og det er ikkje det dei fleste byggjer. Å opne Tor Browser ved sida av ein vanleg VPN-klient tvingar ingen av dei to programma til å bruke vegen til den andre.

Gå gjennom kontrollane i rekkjefølgje. Kvar av dei avgjer om den neste er verdt å starte.

Kva rekkjefølgje byggjer du eigentleg

To rekkjefølgjer blir blanda i same samtale. Tor først tyder at VPN-klienten når serveren sin gjennom ein SOCKS-proxy, slik at tunnelen blir bygd oppå Tor. VPN først tyder at Tor-trafikk går ut gjennom tunnelen, noko dei fleste byggjer ved eit uhell og deretter skildrar som den andre. Den første samlar vidaresendingsgrensa hos VPN-operatøren, den andre samlar ho ved Tor-inngangen og -utgangen. Ingen av dei er det du får ved å ha begge programma opne samstundes.

Skriv ned kva rekkjefølgje oppgåva treng, før du konfigurerer noko, fordi dei to krev ulike programvareinnstillingar og feilar på ulike stader. Ein feilmerkt rekkjefølgje sender deg til å feilsøkje feil lag i ein time. Alt nedanfor føreset Tor først.

Kontroller transporten før alt anna

SOCKS-grensesnittet til Tor ber TCP-straumar og gir ikkje ei generell UDP-tilknyting. Ein VPN der transporten er UDP kan ikkje handsame den proxyen som eit vanleg nettverksgrensesnitt, og inga klientinnstilling endrar kva proxyen er villig til å vidaresende. WireGuard i si vanlege form er det openberre offeret. Ein OpenVPN-profil i TCP-modus er den vanlege løysinga, og han må framleis få beskjed uttrykkeleg om å bruke proxyen.

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

Stadfest at proxyen lyttar og kan bere éin vanleg HTTPS-førespurnad før du feilsøkjer ein tunnel gjennom han. Viss den vanlege førespurnaden feilar, vil VPN-klienten aldri lukkast, og loggane hans vil ikkje fortelje deg kvifor.

Skriv om observatørkartet

Tor-inngangen kan sjå kjelda som koplar til Tor med mindre noko tidlegare har endra ho, så det hoppet lærer adressa di. VPN-leverandøren mottek ei tilkopling som kjem frå Tor-sida, men kan framleis kjenne ein konto, ein betalingspost eller ein legitimasjon du sende inne i tunnelen. Destinasjonar som blir nådde gjennom VPN-en, ser utgangen hans i staden for Tor-utgangen, og det samlar den endelege vidaresendingsgrensa hos éin operatør.

Han gjenopprettar heller ikkje ein distribuert veg til kvar destinasjon. Tor Browser byggjer ein fersk krins per nettstad; ein VPN boren over Tor byggjer éin tunnel, og kvar nettstad bak han deler det endepunktet. Handsame skilnaden som eit designfaktum, ikkje som ei avgrensing som skal tunast bort.

Tel feillaga når det ryker

Eit øydelagt oppsett har minst fire uavhengige lag: SOCKS-tilkoplinga, TLS-handtrykket med VPN-serveren, sjølve VPN-handtrykket og deretter ruting eller namneoppslag inne i tunnelen. Kvart feilar med eit anna symptom, og kvart treng ei anna reparasjon. Å lempe på sertifikatkontrollane fordi tunnelen ikkje kjem opp, er den klassiske feildiagnosen, og han gjer eit transportproblem om til eit tryggleiksproblem.

Logg det første laget som feilar, og stopp der. Ei proxyavvising og ein avvist nøkkel er ikkje variasjonar av same hending.

Stopp viss trugsmålmodellen treng forsvaret til Tor Browser

Å rute vilkårlege applikasjonar gjennom ein VPN boren av Tor gir ikkje desse applikasjonane fingeravtrykk- og isolasjonsfunksjonane til Tor Browser. Kontoane, identifikatorane og deira eigen nettverksåtferd er framleis relevante, og ein tunnel normaliserer ingen av dei. Viss målet er ein nettlesar som smeltar saman med andre brukarar, leverer ikkje denne rekkjefølgja det.

Tor Project sjølv åtvarar mot kombinasjonar som brukarar ikkje kan konfigurere rett, og denne gjeld for dei fleste. Det er eit medvite design for ein smal trugsmålmodell, ikkje ein snareveg til anonym trafikk på heile eininga.