Tor over VPN: kven ser IP-adressa di, og kven ser at du brukar Tor?

Du koplar til VPN-klienten, ventar på tunnelen og opnar så Tor Browser og lèt han byggje ein krins. Nettopp denne vanlege rekkjefølgja avgjer kven som ser kva. I den rekkjefølgja helsar Tors inngangsrelé på VPN-utgangsadressa di, og VPN-leverandøren din helsar på eit offentleg vaktrelé. Gjer det motsette, og begge observatørane endrar seg. Begge rekkjefølgjene er verd ein gjennomgang, fordi klientinnstillingar stille bryt rekkjefølgja folk trudde var på plass, og kontrollen som fangar det opp, er den same i begge tilfelle.

Start med rekkjefølgja, ikkje produktet

To oppsett blir kalla «VPN med Tor», og berre det første er vanleg. Med Tor over VPN er tunnelen alt oppe når Tor startar, så tor-prosessen sender vaktforbindinga si inn i tunnelen som all annan utgåande trafikk. Med VPN over Tor kjem Tor opp først, og sjølve VPN-økta reiser gjennom krinsen og kjem til leverandøren frå ein Tor-utgang.

Det som endrar seg mellom dei, er kva adresse som står i den fjernaste enden av den ytste lenkja. Kvar observatør ser berre førre hopp, aldri heile vegen: vakta ser kven som kopla til henne, og VPN-tenaren ser kven som kopla til han. Tor ber ikkje den lokale tunneladressa di utover, og det finst ikkje noko felt i protokollen der han kunne gjere det.

I begge rekkjefølgjene ser mål-nettstaden framleis ein Tor-utgang, og ingen av rekkjefølgjene endrar det nettstaden lærer frå innlogginga di. Skilnaden er avgrensa til dei to kantane.

Kva Tors inngangsrelé ser

Inngangen, eller vakta, tek imot ei vanleg TCP-forbinding på ein reléport og byrjar eit TLS-handtrykk med klienten. I eit Tor-over-VPN-oppsett er kjelda til den forbindinga VPN-utgangen din. I eit Tor-først-oppsett er det adressa maskinen din brukte for å nå Tor-nettverket, vanlegvis heimeforbindinga di.

Det svarar på IP-halvdelen av spørsmålet, men berre om tunnelen faktisk bar forbindinga. Tor-prosessen når vakta med sin eigen socket, og den socketen blir ikkje styrt av proxyinnstillingane til Tor Browser. Nettlesaren snakkar med den medfølgjande tor-prosessen over SOCKS på 9150, og tor opnar deretter si eiga forbinding ved hjelp av rutetabellen til kjernen. Ei Socks5Proxy-linje i torrc, eller ein klienttransport, endrar den vegen. Ingenting anna.

På Linux kan du lese svaret av maskinen. Spør kjernen kva grensesnitt han ville brukt for ei vilkårleg offentleg adresse, og sjå deretter på den lokale adressa til den etablerte forbindinga:

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

Viss ruta seier dev wg0 eller dev tun0, og den lokale adressa på den etablerte forbindinga er tunneladressa, er Tor inne i VPN-en. Viss ruta nemner det fysiske grensesnittet ditt, er han utanfor, uansett kva indikatoren til klienten sjølv påstår.

Kva VPN-leverandøren din kan sjå

Leverandøren avsluttar VPN-økta di, så han ser adressene du koplar til. Vaktreléadresser blir publiserte i den offentlege konsensusen, og portane deira er godt kjende, så å matche ei er eit listesøk og ikkje djup pakkeinspeksjon. Ein leverandør treng ikkje å bryte Tor for å vite at ei økt er Tor.

Det han ikkje ser, er resten av krinsen. Det midtre reléet og utgangen blir valde inne i Tor, og leverandøren handterer berre lenkja til vakta. Sideinnhald blir verande i TLS som blir avslutta ved utgangen, og namneoppslag for Tor-trafikk skjer òg ved utgangen, så det finst inga DNS-spørjing hos leverandøren å korrelere med ein destinasjon.

Bruer med obfs4 endrar søket, ikkje topologien. Ei bru-adresse manglar i den offentlege relélista, og trafikken blir forma for ikkje å sjå ut som Tor, så ein operatør som berre samanliknar adresser, vil ikkje flagge henne. Økta kjem framleis frå VPN-klienten din, og leverandøren ser framleis eitt endepunkt, eitt volum og éin tidsplan.

Evne er ikkje ein oppbevaringspolicy

Ein operatør som kan observere ei forbinding, har ikkje lova å behalde henne. Logging er eit eige vedtak, skrive ned i ein policy, avgrensa av jurisdiksjon og berre kontrollerbart gjennom bevis du alt stolar på. Eit no-logs-merke endrar ikkje nettverksrolla som er skildra ovanfor.

Kontoidentitet betyr vanlegvis meir enn utgangsadressa. Viss du logga inn med ei e-postadresse, eller betalte med kort, kan leverandøren knyte økta til deg utan å logge ein einaste destinasjon. Å rotere utgangs-IP-ar gjer ingenting med det.

Sjekk dekninga før du stolar på noko av dei to svara

Dei fleste som trur dei køyrer Tor over VPN, køyrer berre ein del av det. Splitt-tunnelering som utelukkar Tor Browser, ein kill switch som dekkjer nettlesaren men ikkje tor-tenesta, ein oppstartseining som køyrer før tunnelen er oppe, og ein IPv6-veg rundt tunnelen er dei vanlege fire.

Å lese statusskjermen til klienten testar ingen av dei. Testen som gjer det: lat Tor Browser køyre, ta tunnelen ned og sjå om vaktforbindinga overlever på det fysiske grensesnittet.

Rekkjefølgja eg sjekkar i, og stoppar ved første feil:

• ip route get 203.0.113.10 returnerer tunneleininga.
• ss -tnp | grep -i tor viser vaktforbindinga med ei lokal tunneladresse.
• ip -6 route har inga standardrute utanfor tunnelen, eller IPv6 er av i klienten.
• Å ta ned VPN-en avsluttar eller omdirigerer tor-forbindinga i staden for å late henne bli på den fysiske lenkja.

Kva rekkjefølgje passar til det du forsvarte

Begge rekkjefølgjene skjuler noko og avdekkjer noko, så svaret er eit val om observatøren du bryr deg om.

Les det kolonne for kolonne til ei rad passar til det du prøver å hindre. Viss uroa er eit lokalt nettverk eller ein ISP som registrerer eller blokkerer Tor, handterer Tor over VPN det. Viss uroa er at VPN-operatøren lærer heimeadressa di, handterer VPN over Tor det, og betaler for det ved å eksponere Tor-bruk for ditt eige nettverk og heimeadressa for vakta.

Ingen av oppsetta lèt begge kantane vere blinde. Å leggje til ein observatør fjernar ikkje ein annan. Notatet til Tor Project om å køyre ein VPN med Tor seier det same frå den andre sida: tunnelen endrar kven som blir stolt på og kva feilvegar som finst, så det er ikkje ei oppgradering å leggje til utan å avgjere kva du ville skjule.

Avgjer observatøren først, vel rekkjefølgja deretter, og verifiser med ip route get og ss i staden for indikatoren til klienten. Viss observatøren er nokon som kan tvinge VPN-leverandøren sjølv, rettar ingen rekkjefølgjeval det.