Tor över VPN: vem ser din IP, och vem ser att du använder Tor?

Du ansluter VPN-klienten, väntar på tunneln och öppnar sedan Tor Browser och låter den bygga en krets. Just den vanliga ordningen avgör vem som ser vad. I den ordningen hälsar Tors ingångsrelä på din VPN-utgångsadress, och din VPN-leverantör hälsar på ett offentligt vaktrelä. Gör tvärtom och båda observatörerna ändras. Båda ordningarna är värda en genomgång, eftersom klientinställningar tyst bryter den ordning folk trodde gällde, och kontrollen som fångar det är densamma i båda fallen.

Börja med ordningen, inte produkten

Två uppsättningar kallas „VPN med Tor“, och bara den första är vanlig. Med Tor över VPN är tunneln redan uppe när Tor startar, så tor-processen skickar sin vaktanslutning in i tunneln som all annan utgående trafik. Med VPN över Tor kommer Tor upp först och själva VPN-sessionen färdas genom kretsen och når leverantören från en Tor-utgång.

Det som ändras mellan dem är vilken adress som står i den bortersta änden av den yttersta länken. Varje observatör ser bara föregående hopp, aldrig hela vägen: vakten ser vem som anslöt till den, och VPN-servern ser vem som anslöt till den. Tor bär inte din lokala tunneladress utåt, och det finns inget fält i protokollet där den skulle kunna göra det.

I båda ordningarna ser destinationswebbplatsen fortfarande en Tor-utgång, och ingen av ordningarna ändrar vad den webbplatsen lär sig av din inloggning. Skillnaden är begränsad till de två kanterna.

Vad Tors ingångsrelä ser

Ingången, eller vakten, tar emot en vanlig TCP-anslutning på en reläport och börjar en TLS-handskakning med klienten. I en Tor-över-VPN-uppsättning är källan till den anslutningen din VPN-utgång. I en Tor-först-uppsättning är det adressen som din maskin använde för att nå Tor-nätverket, vanligtvis din hemanslutning.

Det svarar på IP-halvan av frågan, men bara om tunneln faktiskt bar anslutningen. Tor-processen når vakten med sin egen socket, och den socketen styrs inte av Tor Browsers proxyinställningar. Webbläsaren talar med den medföljande tor-processen över SOCKS på 9150, och sedan öppnar tor sin egen anslutning med hjälp av kärnans routingtabell. En Socks5Proxy-rad i torrc, eller en klienttransport, ändrar den vägen. Inget annat.

På Linux kan du läsa av svaret från maskinen. Fråga kärnan vilket gränssnitt den skulle använda för en godtycklig offentlig adress, och titta sedan på den lokala adressen för den etablerade anslutningen:

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

Om rutten säger dev wg0 eller dev tun0, och den lokala adressen på den etablerade anslutningen är tunneladressen, är Tor inne i VPN:en. Om rutten namnger ditt fysiska gränssnitt är den utanför, vad klientens egen indikator än påstår.

Vad din VPN-leverantör kan se

Leverantören avslutar din VPN-session, så den ser de adresser du ansluter till. Vaktreläadresser publiceras i den offentliga konsensusen och deras portar är välkända, så att matcha en är en listkontroll och inte djup paketinspektion. En leverantör behöver inte bryta Tor för att veta att en session är Tor.

Det den inte ser är resten av kretsen. Det mittersta reläet och utgången väljs inne i Tor, och leverantören hanterar bara länken till vakten. Sidinnehåll stannar i TLS som avslutas vid utgången, och namnuppslag för Tor-trafik sker också vid utgången, så det finns ingen DNS-förfrågan hos leverantören att korrelera med en destination.

Broar med obfs4 ändrar sökningen, inte topologin. En broadress saknas i den offentliga relälistan och trafiken formas för att inte se ut som Tor, så en operatör som bara jämför adresser flaggar den inte. Sessionen kommer fortfarande från din VPN-klient, och leverantören ser fortfarande en slutpunkt, en volym och ett schema.

Förmåga är inte en bevarandepolicy

En operatör som kan observera en anslutning har inte lovat att behålla den. Loggning är ett separat beslut, nedskrivet i en policy, begränsat av jurisdiktion och bara kontrollerbart genom bevis du redan litar på. Etiketten utan loggar ändrar inte nätverksrollen som beskrivs ovan.

Kontoidentitet spelar vanligtvis större roll än utgångsadressen. Om du loggade in med en e-postadress, eller betalade med kort, kan leverantören knyta sessionen till dig utan att logga en enda destination. Att rotera utgående IP-adresser gör ingenting åt det.

Kontrollera täckningen innan du litar på något av de två svaren

De flesta som tror att de kör Tor över VPN kör bara en del av det. Delad tunnling som utesluter Tor Browser, en kill switch som täcker webbläsaren men inte tor-tjänsten, en startenhet som körs innan tunneln är uppe, och en IPv6-väg runt tunneln är de vanliga fyra.

Att läsa klientens statusskärm testar ingen av dem. Testet som gör det: låt Tor Browser köra, ta ner tunneln och se om vaktanslutningen överlever på det fysiska gränssnittet.

Ordningen jag kontrollerar i, och stannar vid första felet:

• ip route get 203.0.113.10 returnerar tunneleenheten.
• ss -tnp | grep -i tor visar vaktanslutningen med en lokal tunneladress.
• ip -6 route har ingen standardrutt utanför tunneln, eller IPv6 är av i klienten.
• Att ta ner VPN:en avslutar eller omdirigerar tor-anslutningen i stället för att lämna den på den fysiska länken.

Vilken ordning som passar det du försvarar

Båda ordningarna döljer något och blottar något, så svaret är ett val om observatören du bryr dig om.

Läs det kolumn för kolumn tills en rad passar det du försöker förhindra. Om oron är ett lokalt nätverk eller en ISP som registrerar eller blockerar Tor, hanterar Tor över VPN det. Om oron är att VPN-operatören får veta din hemadress, hanterar VPN över Tor det, och betalar för det genom att blotta Tor-användning för ditt eget nätverk och hemadressen för vakten.

Ingen av uppsättningarna lämnar båda kanterna blinda. Att lägga till en observatör tar inte bort en annan. Tor Projects notis om att köra en VPN med Tor säger samma sak från andra hållet: tunneln ändrar vem som litas på och vilka felvägar som finns, så det är inte en uppgradering att lägga till utan att bestämma vad du ville dölja.

Bestäm observatören först, välj ordningen sedan, och verifiera med ip route get och ss i stället för klientens indikator. Om observatören är någon som kan tvinga VPN-leverantören själv, rättar inget ordningsval det.