Tor over VPN: hvem ser din IP, og hvem ser, at du bruger Tor?

Du tilslutter VPN-klienten, venter på tunnelen og åbner derefter Tor Browser, så den kan bygge et kredsløb. Den ganske almindelige rækkefølge er det, der afgør, hvem der ser hvad. I den rækkefølge hilser Tors indgangsrelæ på din VPN-udgangsadresse, og din VPN-udbyder hilser på et offentligt guard-relæ. Gør det omvendt, og begge observatører ændrer sig. Begge rækkefølger er værd at gennemgå, fordi klientindstillinger stille bryder den rækkefølge, folk troede var på plads, og den kontrol, der fanger det, er den samme i begge tilfælde.

Start med rækkefølgen, ikke produktet

To arrangementer kaldes „VPN med Tor“, og kun det første er almindeligt. Ved Tor over VPN er tunnelen allerede oppe, når Tor starter, så tor-processen sender sin guard-forbindelse ind i tunnelen som al anden udgående trafik. Ved VPN over Tor kommer Tor først op, og selve VPN-sessionen rejser gennem kredsløbet og ankommer til udbyderen fra en Tor-udgang.

Det, der ændrer sig mellem dem, er, hvilken adresse der står i den fjerneste ende af det yderste led. Enhver observatør ser kun det foregående hop, aldrig hele vejen: guard ser, hvem der har forbundet til den, og VPN-serveren ser, hvem der har forbundet til den. Tor bærer ikke din lokale tunneladresse udad, og der er intet felt i protokollen, hvor den kunne gøre det.

I begge rækkefølger ser destinationswebstedet stadig en Tor-udgang, og ingen af rækkefølgerne ændrer, hvad det websted lærer af dit login. Forskellen er begrænset til de to kanter.

Hvad Tors indgangsrelæ ser

Indgangen, eller guarden, accepterer en almindelig TCP-forbindelse på en relæport og begynder en TLS-handshake med klienten. I et Tor-over-VPN-setup er kilden til den forbindelse din VPN-udgang. I et Tor-først-setup er det den adresse, din maskine brugte til at nå Tor-netværket, normalt din hjemmeforbindelse.

Det besvarer IP-halvdelen af spørgsmålet, men kun hvis tunnelen faktisk har båret forbindelsen. Tor-processen når guarden med sin egen socket, og den socket styres ikke af Tor Browsers proxyindstillinger. Browseren taler med den medfølgende tor-process over SOCKS på 9150, og tor åbner derefter sin egen forbindelse ved hjælp af kernens routingtabel. En Socks5Proxy-linje i torrc eller en klienttransport ændrer den vej. Intet andet.

På Linux kan du læse svaret af maskinen. Spørg kernen, hvilken grænseflade den ville bruge til en vilkårlig offentlig adresse, og se derefter på den lokale adresse på den etablerede forbindelse:

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

Hvis ruten siger dev wg0 eller dev tun0, og den lokale adresse på den etablerede forbindelse er tunneladressen, er Tor inde i VPN'en. Hvis ruten nævner din fysiske grænseflade, er den udenfor, hvad end klientens egen indikator påstår.

Hvad din VPN-udbyder kan se

Udbyderen afslutter din VPN-session, så den ser de adresser, du forbinder til. Guard-relæadresser offentliggøres i den offentlige konsensus, og deres porte er velkendte, så at matche en er et listeslag snarere end dyb pakkeinspektion. En udbyder behøver ikke bryde Tor for at vide, at en session er Tor.

Det, den ikke ser, er resten af kredsløbet. Det midterste relæ og udgangen vælges inde i Tor, og udbyderen håndterer kun leddet til guarden. Sideindhold bliver inde i TLS, der terminerer ved udgangen, og navneopløsning for Tor-trafik sker også ved udgangen, så der er ingen DNS-forespørgsel hos udbyderen at korrelere med en destination.

Broer med obfs4 ændrer opslaget, ikke topologien. En broadresse mangler i den offentlige relæliste, og trafikken formes til ikke at ligne Tor, så en operatør, der kun sammenligner adresser, vil ikke flagge den. Sessionen kommer stadig fra din VPN-klient, og udbyderen ser stadig et endepunkt, et volumen og en tidsplan.

Evne er ikke en opbevaringspolitik

En operatør, der kan observere en forbindelse, har ikke lovet at beholde den. Logning er en separat beslutning, skrevet ned i en politik, begrænset af jurisdiktion og kun kontrollerbar gennem beviser, du allerede stoler på. Et no-logs-mærke ændrer ikke den netværksrolle, der er beskrevet ovenfor.

Kontoidentitet betyder normalt mere end udgangsadressen. Hvis du loggede ind med en e-mailadresse eller betalte med kort, kan udbyderen knytte sessionen til dig uden at logge en enkelt destination. At rotere udgangs-IP'er gør intet ved det.

Kontroller dækningen, før du stoler på noget af svaret

De fleste, der tror, de kører Tor over VPN, kører kun en del af det. Split tunneling, der udelukker Tor Browser, en kill switch, der dækker browseren men ikke tor-tjenesten, en opstartsunit, der kører før tunnelen er oppe, og en IPv6-vej uden om tunnelen er de sædvanlige fire.

At læse klientens statusskærm tester ingen af dem. Testen, der gør: lad Tor Browser køre, tag tunnelen ned, og se, om guard-forbindelsen overlever på den fysiske grænseflade.

Den rækkefølge, jeg kontrollerer i, og stopper ved den første fejl:

• ip route get 203.0.113.10 returnerer tunneleenheden.
• ss -tnp | grep -i tor viser guard-forbindelsen med en lokal tunneladresse.
• ip -6 route har ingen standardrute uden for tunnelen, eller IPv6 er slået fra i klienten.
• At droppe VPN'en afslutter eller omdirigerer tor-forbindelsen i stedet for at lade den blive på det fysiske led.

Hvilken rækkefølge passer til det, du forsvarer

Begge rækkefølger skjuler noget og blotlægger noget, så svaret er et valg om den observatør, du bekymrer dig om.

Læs det kolonne for kolonne, indtil en række passer til det, du prøver at forhindre. Hvis bekymringen er et lokalt netværk eller en ISP, der registrerer eller blokerer Tor, klarer Tor over VPN det. Hvis bekymringen er, at VPN-operatøren lærer din hjemadresse, klarer VPN over Tor det og betaler for det ved at blotte Tor-brug for dit eget netværk og din hjemadresse for guarden.

Ingen af arrangementerne efterlader begge kanter blinde. At tilføje en observatør fjerner ikke en anden. Tor Projects note om at køre en VPN med Tor siger det samme fra den anden side: tunnelen ændrer, hvem der stoles på, og hvilke fejlveje der findes, så det er ikke en opgradering at tilføje uden at beslutte, hvad du ville skjule.

Beslut observatøren først, vælg rækkefølgen derefter, og verificér med ip route get og ss i stedet for klientens indikator. Hvis observatøren er nogen, der kan tvinge VPN-udbyderen selv, retter intet valg af rækkefølge det.