VPN före Tor: vad ordningen egentligen ändrar

Att ansluta VPN först ger en bestämd kedja: enhet, VPN-slutpunkt, Tor-ingång, Tor-krets, destination. Ditt lokala nätverk ser en krypterad anslutning till VPN, och Tor-ingångsnoden ser VPN-utgången som omedelbar källa i stället för din leverantörs adress. VPN-operatören ser i sin tur anslutningar mot Tor-ingångsinfrastrukturen och kan härleda Tor-användning från destinationerna. Varje observatör förlorar något och vinner något, därför är ordningen ett byte och inte en uppgradering.

Ingenting i den kedjan ändrar vad webbplatsen lär sig från ditt konto, cookies eller inskrivna uppgifter.

Vad ordningen ändrar

Det lokala nätverket och internetleverantören förlorar direkt insyn i din Tor-trafik, eftersom första hoppet nu är en krypterad tunnel till en leverantör. Tor-ingångsvakten förlorar din hemadress och ser VPN-utgången. VPN-leverantören får de metadata som din internetleverantör tidigare hade: vilka adresser du kontaktar, vid vilka tider och hur mycket data som rör sig.

Bortom ingångsvakten beter sig kretsen som förut. Reläerna skiljer fortfarande rollerna ingång, mitt och utgång, och VPN ser inte det slutliga innehållet mer än din internetleverantör gjorde.

Bekräfta vägen som faktiskt används

Delad tunnling är det vanliga skälet till att den avsedda kedjan inte är den verkliga.Om Tor Browser är utesluten från tunneln, eller en andra profil dirigerar annorlunda, ser ingångsvakten leverantörens adress igen medan gränssnittet fortfarande ser anslutet ut. Kontrollera vägen och den observerade utgången i stället för ikonen.

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

SOCKS-begäran via port 9150 besvaras av Tor Browsers egen klient, så ett svar på IsTor true bekräftar webbläsarens krets, inte att alla andra program använder den. Det är värt att registrera resolverns utdata eftersom DNS kan gå ut via en väg som tunneln inte täcker. Spara båda utdata med tidsstämpel. De är baslinjen för nästa jämförelse.

Jämför med en direkt begäran från en vanlig terminal: om den också rapporterar Tor, omdirigerar något annat trafiken och kedjan är inte vad designen antog.

Se vad som händer när tunneln faller

En klient som tyst faller tillbaka till det lokala gränssnittet ändrar källan som ingångsvakten ser, och användaren vet oftast inte om det eftersom sidan fortfarande laddas. Det är det felet som är värt att testa, inte den lyckliga vägen. Koppla från tunneln med avsikt och se om Tor-trafiken stannar eller fortsätter oskyddad.

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

Brandväggsregler som blockerar utgående trafik utanför tunneln är den enda pålitliga reservkontrollen, och de måste täcka både webbläsarens SOCKS-klient och alla andra program du bryr dig om. Ett webbläsartillägg är inte en enhets-VPN och påverkar inte andra program eller externa observatörer.

Avgör om det extra lagret förtjänar sitt förtroende

Tor Project avråder från att stapla en VPN under Tor om du inte själv kan utvärdera inställningen. Det angivna skälet är det extra beroendet: en annan part, ett annat konto och ett annat felläge. Om målet är att hindra din internetleverantör från att se att du använder Tor, riktar VPN sig mot just den observatören. Om målet är starkare anonymitet mot en global observatör levererar VPN inte det.

Den omvända ordningen finns också, och namnen är inte utbytbara:Tor over VPN och VPN over Tor beskriver olika förtroendeförhållanden och olika felbeteende. Läs jämförelsen innan du blandar dem.

Skriv ner vilken observatör du försöker flytta, bekräfta sedan att den verkliga vägen matchar designen, och bekräfta sedan felbeteendet. Om de tre svaren inte rättfärdigar det extra kontot och konfigurationen har den dokumenterade Tor Browser-inställningen färre delar som kan gå fel.