VPN ind i Tor, Tor ind i VPN: hvorfor kæden knækker
Når en VPN, Tor og en proxy stables, afgør rækkefølgen, hvad der slås op, og hvad der bæres. Find den første brudte grænse, før du ændrer alle tre.
At stable en VPN, Tor og en applikationsproxy føles som at mangfoldiggøre privatliv, og det mangfoldiggør antallet af steder, hvor en forbindelse kan dø. Det sædvanlige resultat er en browser, der snurrer, mens tre værktøjer hver især melder sig raske. Ændrer man alle tre indstillinger på én gang, fjerner man samtidig det eneste spor af, hvilket af dem der lyver.
Tegn først den tilsigtede vej i rækkefølge, og navngiv hvilket program der åbner hver forbindelse, og hvilket navn der slås op ved hvert trin.
Lag lægger sig ikke sammen, de virker ind på hinanden
En VPN før Tor betyder, at Tor-klientens indgangsforbindelse rejser inde i tunnelen. En VPN, der bæres gennem Tor, betyder, at VPN-klientens eget endepunkt skal kunne nås over Tor, hvilket er et helt andet krav. Browserens proxy tilføjer endnu et hop, som styresystemet intet ved om. Tre arrangementer, tre separate afhængighedslister.
Hvert arrangement ændrer, hvad der kan slås op, hvad der kan bæres, og hvem der ser den første pakke. Kun ét af dem kan være den opsætning, du mente.
Tilføj også den direkte vej til diagrammet. En fallback-rute, en undtagelse i delt tunnel eller en proxy-omvej kan få en side til at indlæse, mens den stille springer den kæde over, du ville teste, og den succes vildleder mere end fejlen.
Rækkefølgen afgør, hvad der kan bæres
Tor bærer TCP-strømme gennem sin SOCKS-grænseflade, og en klient, der beder proxyen slå værtsnavnet op, holder opslaget inde i kredsløbet. UDP rejser ikke sådan i almindelige opsætninger, og derfor kan en WireGuard-tunnel ikke indlejres i Tor uden et ekstra TCP-relæ i midten.
OpenVPN kan tvinges til TCP, så det arrangement er i det mindste beskriveligt. Det er også langsommere og mere skrøbeligt, og fejltilstanden, når det knækker, ser ud som en blokeret port. Forvent at bruge længere tid på at skelne de to end på at reparere nogen af dem.
Opslag er den anden halvdel. Med --socks5-hostname slår proxyen destinationen op, mens almindelig --socks5 først spørger den lokale resolver og lækker navnet ud af kredsløbet. Netop det ene flag afgør, om navneopslaget hører til kæden eller til din udbyder.
| 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 |
At finde den første brudte grænse
Test etaperne i den rækkefølge, pakkerne rejser, med uskadelige forespørgsler, og stop ved den første, der fejler. Noter, hvilken kommando der kørte først, for rækkefølgen er en del af beviset. To kommandoer skelner et dødt kredsløb fra en død udgang:
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ørste rapporterer, om en forespørgsel overhovedet fuldføres gennem SOCKS-proxyen, og den anden viser den adresse, netværket præsenterer lige nu. Hvis den første fejler og den anden lykkes, sidder problemet ved eller før Tor-klienten. Hvis begge lykkes og browseren stadig fejler, bruger applikationen en anden vej end skallen.
En side med offentlig IP beskriver også kun den sidste synlige udgang. Den kan ikke fortælle, hvor mange hop der gik forud, så par den med hvert værktøjs understøttede statusoutput i stedet for at behandle ét tal som et diagram.
Hvornår man skal holde op med at tilføje lag
Hvis du ikke kan sige på én sætning, hvad et lag bidrager med, så fjern det. En kæde, hvis formål er uklart, er en kæde, ingen kan fejlfinde klokken tre om natten, og privatlivsgevinsten ved et uforklaret hop er som regel mindre end den tilgængelighed, du mister.
Hvis et lag virkelig fortjener sin plads, test det alene først, tilføj så det næste og bekræft vejen igen med de samme to kommandoer. Gendan den fulde kæde før almindelig brug, og hold TLS-validering og godkendelse slået til; en certifikatadvarsel, der accepteres for at få en side til at indlæse, er en routing-omvej, ikke en reparation. Skriv den rækkefølge ned, du landede på, mens den er frisk.
Skriv den rækkefølge ned, inklusive den resolver, der svarer på hvert trin. En fungerende kæde, du kan beskrive, overlever den næste opdatering, mens en fungerende kæde, du samlede ved at prøve dig frem, forsvinder med den. Tilføj dato og versioner, så en senere fejl kan sammenlignes med en kendt god tilstand i stedet for at blive diskuteret fra hukommelsen. Ti linjer i en tekstfil sparer en aften med gætterier.