Tor over VPN: hvem ser IP-adressen din, og hvem ser at du bruker Tor?

Du kobler til VPN-klienten, venter på tunnelen og åpner så Tor Browser og lar den bygge en krets. Denne vanlige rekkefølgen er det som avgjør hvem som ser hva. I den rekkefølgen hilser Tors inngangsrelé på VPN-utgangsadressen din, og VPN-leverandøren din hilser på et offentlig vaktrelé. Gjør det motsatte, og begge observatørene endres. Begge rekkefølgene er verdt en gjennomgang, fordi klientinnstillinger stille bryter rekkefølgen folk trodde var på plass, og kontrollen som fanger det opp, er den samme i begge tilfeller.

Start med rekkefølgen, ikke produktet

To oppsett kalles «VPN med Tor», og bare det første er vanlig. Med Tor over VPN er tunnelen allerede oppe når Tor starter, så tor-prosessen sender vaktforbindelsen sin inn i tunnelen som all annen utgående trafikk. Med VPN over Tor kommer Tor opp først, og selve VPN-økten reiser gjennom kretsen og ankommer leverandøren fra en Tor-utgang.

Det som endres mellom dem, er hvilken adresse som står i den fjerneste enden av den ytterste lenken. Hver observatør ser bare forrige hopp, aldri hele veien: vakten ser hvem som koblet til den, og VPN-serveren ser hvem som koblet til den. Tor bærer ikke din lokale tunneladresse utover, og det finnes ikke noe felt i protokollen der den kunne gjøre det.

I begge rekkefølgene ser destinasjonsnettstedet fortsatt en Tor-utgang, og ingen av rekkefølgene endrer det nettstedet lærer fra innloggingen din. Forskjellen er begrenset til de to kantene.

Hva Tors inngangsrelé ser

Inngangen, eller vakten, godtar en vanlig TCP-forbindelse på en reléport og begynner en TLS-håndtrykk med klienten. I et Tor-over-VPN-oppsett er kilden til den forbindelsen VPN-utgangen din. I et Tor-først-oppsett er det adressen maskinen din brukte for å nå Tor-nettverket, vanligvis hjemmeforbindelsen din.

Det svarer på IP-halvdelen av spørsmålet, men bare hvis tunnelen faktisk bar forbindelsen. Tor-prosessen når vakten med sin egen socket, og den socketen styres ikke av Tor Browsers proxyinnstillinger. Nettleseren snakker med den medfølgende tor-prosessen over SOCKS på 9150, og tor åpner deretter sin egen forbindelse ved hjelp av kjernens rutetabell. En Socks5Proxy-linje i torrc, eller en klienttransport, endrer den veien. Ingenting annet.

På Linux kan du lese svaret av maskinen. Spør kjernen hvilket grensesnitt den ville brukt for en vilkårlig offentlig adresse, og se deretter på den lokale adressen til den etablerte forbindelsen:

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

Hvis ruten sier dev wg0 eller dev tun0, og den lokale adressen på den etablerte forbindelsen er tunneladressen, er Tor inne i VPN-en. Hvis ruten nevner det fysiske grensesnittet ditt, er den utenfor, uansett hva klientens egen indikator påstår.

Hva VPN-leverandøren din kan se

Leverandøren avslutter VPN-økten din, så den ser adressene du kobler til. Vaktreléadresser publiseres i den offentlige konsensusen, og portene deres er godt kjent, så å matche en er et listesøk og ikke dyp pakkeinspeksjon. En leverandør trenger ikke å bryte Tor for å vite at en økt er Tor.

Det den ikke ser, er resten av kretsen. Det midterste reléet og utgangen velges inne i Tor, og leverandøren håndterer bare lenken til vakten. Sideinnhold blir værende i TLS som avsluttes ved utgangen, og navneoppslag for Tor-trafikk skjer også ved utgangen, så det finnes ingen DNS-spørring hos leverandøren å korrelere med en destinasjon.

Broer med obfs4 endrer søket, ikke topologien. En bro-adresse mangler i den offentlige relélisten, og trafikken formes for ikke å se ut som Tor, så en operatør som bare sammenligner adresser, vil ikke flagge den. Økten kommer fortsatt fra VPN-klienten din, og leverandøren ser fortsatt ett endepunkt, ett volum og én tidsplan.

Evne er ikke en oppbevaringspolicy

En operatør som kan observere en forbindelse, har ikke lovet å beholde den. Logging er en egen beslutning, skrevet ned i en policy, begrenset av jurisdiksjon og bare kontrollerbar gjennom bevis du allerede stoler på. Et no-logs-merke endrer ikke nettverksrollen beskrevet ovenfor.

Kontoidentitet betyr vanligvis mer enn utgangsadressen. Hvis du logget inn med en e-postadresse, eller betalte med kort, kan leverandøren knytte økten til deg uten å logge en eneste destinasjon. Å rotere utgangs-IP-er gjør ingenting med det.

Sjekk dekningen før du stoler på noen av de to svarene

De fleste som tror de kjører Tor over VPN, kjører bare en del av det. Splitt-tunneling som utelukker Tor Browser, en kill switch som dekker nettleseren men ikke tor-tjenesten, en oppstartsenhet som kjører før tunnelen er oppe, og en IPv6-vei rundt tunnelen er de vanlige fire.

Å lese klientens statusskjerm tester ingen av dem. Testen som gjør det: la Tor Browser kjøre, ta tunnelen ned og se om vaktforbindelsen overlever på det fysiske grensesnittet.

Rekkefølgen jeg sjekker i, og stopper ved første feil:

• ip route get 203.0.113.10 returnerer tunneleenheten.
• ss -tnp | grep -i tor viser vaktforbindelsen med en lokal tunneladresse.
• ip -6 route har ingen standardrute utenfor tunnelen, eller IPv6 er av i klienten.
• Å ta ned VPN-en avslutter eller omdirigerer tor-forbindelsen i stedet for å la den bli på den fysiske lenken.

Hvilken rekkefølge passer til det du forsvarer

Begge rekkefølgene skjuler noe og avdekker noe, så svaret er et valg om observatøren du bryr deg om.

Les det kolonne for kolonne til en rad passer til det du prøver å forhindre. Hvis bekymringen er et lokalt nettverk eller en ISP som registrerer eller blokkerer Tor, håndterer Tor over VPN det. Hvis bekymringen er at VPN-operatøren lærer hjemadressen din, håndterer VPN over Tor det, og betaler for det ved å eksponere Tor-bruk for ditt eget nettverk og hjemadressen for vakten.

Ingen av oppsettene lar begge kantene være blinde. Å legge til en observatør fjerner ikke en annen. Tor Projects notat om å kjøre en VPN med Tor sier det samme fra den andre siden: tunnelen endrer hvem som stoles på og hvilke feilveier som finnes, så det er ikke en oppgradering å legge til uten å bestemme hva du ville skjule.

Bestem observatøren først, velg rekkefølgen deretter, og verifiser med ip route get og ss i stedet for klientens indikator. Hvis observatøren er noen som kan tvinge VPN-leverandøren selv, retter ingen rekkefølgevalg det.