VPN in i Tor, Tor in i VPN: varför kedjan brister
När en VPN, Tor och en proxy staplas avgör ordningen vad som slås upp och vad som bärs. Hitta den första brutna gränsen innan du ändrar alla tre.
Att stapla en VPN, Tor och en applikationsproxy känns som att mångfaldiga integriteten, och det mångfaldigar antalet platser där en anslutning kan dö. Det vanliga resultatet är en webbläsare som snurrar medan tre verktyg var för sig rapporterar sig friska. Ändrar man alla tre inställningarna på en gång tar man samtidigt bort den enda ledtråden om vilket av dem som ljuger.
Rita först den avsedda vägen i ordning, och namnge vilket program som öppnar varje anslutning och vilket namn som slås upp i varje steg.
Lager adderas inte, de påverkar varandra
En VPN före Tor betyder att Tor-klientens ingångsanslutning reser inne i tunneln. En VPN som bärs genom Tor betyder att VPN-klientens egen ändpunkt måste vara nåbar över Tor, vilket är ett helt annat krav. Webbläsarens proxy lägger till ytterligare ett hopp som operativsystemet inte vet något om. Tre arrangemang, tre separata beroendelistor.
Varje arrangemang ändrar vad som kan slås upp, vad som kan bäras och vem som ser det första paketet. Bara ett av dem kan vara den konfiguration du menade.
Lägg också till den direkta vägen i diagrammet. En reservväg, ett undantag för delad tunnel eller en proxy-omväg kan få en sida att laddas medan den tyst hoppar över kedjan du ville testa, och en sådan framgång vilseleder mer än felet.
Ordningen avgör vad som kan bäras
Tor bär TCP-strömmar genom sitt SOCKS-gränssnitt, och en klient som ber proxyn slå upp värdnamnet håller uppslaget inne i kretsen. UDP reser inte så i vanliga konfigurationer, därför kan en WireGuard-tunnel inte bäddas in i Tor utan en extra TCP-relä i mitten.
OpenVPN kan tvingas till TCP, så det arrangemanget är åtminstone beskrivbart. Det är också långsammare och ömtåligare, och felmoden när det brister ser identisk ut med en blockerad port. Räkna med att lägga mer tid på att skilja de två än på att reparera någon av dem.
Uppslagningen är den andra halvan. Med --socks5-hostname slår proxyn upp målet, medan vanlig --socks5 först frågar den lokala resolvern och läcker namnet utanför kretsen. Just den enda flaggan avgör om namnsökningen hör till kedjan eller till din leverantör.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Att hitta den första brutna gränsen
Testa stegen i den ordning paketen reser, med ofarliga förfrågningar, och stanna vid det första som misslyckas. Notera vilket kommando som kördes först, eftersom ordningen är en del av beviset. Två kommandon skiljer en död krets från en död utgång:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Den första rapporterar om en förfrågan över huvud taget slutförs genom SOCKS-proxyn, och den andra visar den adress nätverket presenterar just nu. Om den första misslyckas och den andra lyckas sitter problemet vid eller före Tor-klienten. Om båda lyckas och webbläsaren ändå misslyckas använder applikationen en annan väg än skalet.
En sida med offentlig IP beskriver också bara den sista synliga utgången. Den kan inte säga hur många hopp som föregick den, så kombinera den med varje verktygs stödda statusutdata i stället för att behandla en enda siffra som ett diagram.
När man ska sluta lägga till lager
Om du inte kan säga i en mening vad ett lager bidrar med, ta bort det. En kedja vars syfte är oklart är en kedja som ingen kan felsöka klockan tre på natten, och integritetsvinsten med ett oförklarat hopp är oftast mindre än den tillgänglighet du förlorar.
Om ett lager verkligen förtjänar sin plats, testa det ensamt först, lägg sedan till nästa och bekräfta vägen igen med samma två kommandon. Återställ hela kedjan före vanlig användning och håll TLS-validering och autentisering påslagna; en certifikatvarning som accepteras för att få en sida att laddas är en routningsomväg, inte en reparation. Skriv ned den ordning du landade på medan den är färsk.
Skriv ned den ordningen, inklusive resolvern som svarar i varje steg. En fungerande kedja som du kan beskriva överlever nästa uppdatering, medan en fungerande kedja som du satte ihop genom att prova försvinner med den. Lägg till datum och versioner, så att ett senare fel kan jämföras med ett känt gott tillstånd i stället för att diskuteras ur minnet. Tio rader i en textfil sparar en kväll av gissningar.