VPN genom Tor: transportkontrollen kommer först

Tor-först betyder att VPN-klienten sitter bakom en SOCKS-proxy, så själva tunneln byggs genom Tor och applikationstrafiken lämnar VPN-slutpunkten. Det är en bestämd ordning, och det är inte det de flesta bygger. Att öppna Tor Browser bredvid en vanlig VPN-klient tvingar ingen av de två programmen att använda den andras väg.

Gå igenom kontrollerna i ordning. Var och en avgör om nästa är värd att börja.

Vilken ordning bygger du egentligen

Två ordningar blandas ihop i samma samtal. Tor först betyder att VPN-klienten når sin server genom en SOCKS-proxy, så tunneln byggs ovanpå Tor. VPN först betyder att Tor-trafik lämnar genom tunneln, vilket de flesta bygger av misstag och sedan beskriver som den andra. Den första samlar vidarebefordringsgränsen hos VPN-operatören, den andra samlar den vid Tor-ingången och -utgången. Ingen av dem är det du får genom att ha båda programmen öppna samtidigt.

Skriv ned vilken ordning uppgiften behöver innan du konfigurerar något, eftersom de två kräver olika programvaruinställningar och misslyckas på olika ställen. En felmärkt ordning skickar dig att felsöka fel lager i en timme. Allt nedan förutsätter Tor först.

Kontrollera transporten före allt annat

Tors SOCKS-gränssnitt bär TCP-strömmar och ger ingen allmän UDP-association. En VPN vars transport är UDP kan inte behandla den proxyn som ett vanligt nätverksgränssnitt, och ingen klientinställning ändrar vad proxyn är villig att vidarebefordra. WireGuard i sin vanliga form är det uppenbara offret. En OpenVPN-profil i TCP-läge är den vanliga lösningen, och den måste fortfarande uttryckligen få veta att proxyn ska användas.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

Bekräfta att proxyn lyssnar och kan bära en vanlig HTTPS-förfrågan innan du felsöker en tunnel genom den. Om den vanliga förfrågan misslyckas kommer VPN-klienten aldrig att lyckas, och dess loggar kommer inte att berätta varför.

Skriv om observatörskartan

Tor-ingången kan se källan som ansluter till Tor om inte något tidigare har ändrat den, så det hoppet lär sig din adress. VPN-leverantören tar emot en anslutning som kommer från Tor-sidan men kan fortfarande känna till ett konto, en betalningspost eller en inloggningsuppgift som du skickade inne i tunneln. Destinationer som nås genom VPN ser dess utgång i stället för Tors utgång, och det samlar den slutliga vidarebefordringsgränsen hos en enda operatör.

Den återskapar inte heller en distribuerad väg till varje destination. Tor Browser bygger en färsk krets per webbplats; en VPN buren över Tor bygger en tunnel, och varje webbplats bakom den delar den slutpunkten. Behandla skillnaden som ett designfaktum och inte som en begränsning som ska tunnas bort.

Räkna fellagren när det går sönder

En trasig uppsättning har minst fyra oberoende lager: SOCKS-anslutningen, TLS-handskakningen med VPN-servern, själva VPN-handskakningen och sedan routing eller namnmatchning inne i tunneln. Varje lager misslyckas med ett annat symptom och varje kräver en annan reparation. Att lätta på certifikatkontrollerna för att tunneln inte kommer upp är den klassiska feldiagnosen, och den förvandlar ett transportproblem till ett säkerhetsproblem.

Logga det första lagret som misslyckas och stanna där. En proxyvägran och en avvisad nyckel är inte variationer av samma händelse.

Stanna om hotmodellen behöver Tor Browsers försvar

Att routa godtyckliga program genom en VPN buren av Tor ger inte de programmen Tor Browsers fingeravtrycks- och isoleringsfunktioner. Deras konton, identifierare och eget nätverksbeteende är fortfarande relevanta, och en tunnel normaliserar inget av det. Om målet är en webbläsare som smälter samman med andra användare levererar denna ordning det inte.

Tor Project självt varnar för kombinationer som användare inte kan konfigurera korrekt, och den här gäller för de flesta. Det är en medveten design för en snäv hotmodell, inte en genväg till anonym trafik på hela enheten.