VPN inn i Tor, Tor inn i VPN: hvorfor kjeden brytes
Når en VPN, Tor og en proxy stables, avgjør rekkefølgen hva som slås opp og hva som bæres. Finn den første brutte grensen før du endrer alle tre.
Å stable en VPN, Tor og en applikasjonsproxy føles som å mangedoble personvernet, og det mangedobler antallet steder der en tilkobling kan dø. Det vanlige resultatet er en nettleser som spinner mens tre verktøy hver for seg melder seg friske. Endrer man alle tre innstillingene på én gang, fjerner man samtidig det eneste sporet av hvilket av dem som lyver.
Tegn først den tiltenkte veien i rekkefølge, og navngi hvilket program som åpner hver tilkobling og hvilket navn som slås opp ved hvert trinn.
Lag legger seg ikke sammen, de virker inn på hverandre
En VPN før Tor betyr at inngangstilkoblingen til Tor-klienten reiser inne i tunnelen. En VPN som bæres gjennom Tor betyr at VPN-klientens eget endepunkt må kunne nås over Tor, noe som er et helt annet krav. Nettleserens proxy legger til ett hopp til som operativsystemet ikke vet noe om. Tre oppsett, tre separate avhengighetslister.
Hvert oppsett endrer hva som kan slås opp, hva som kan bæres og hvem som ser den første pakken. Bare ett av dem kan være konfigurasjonen du mente.
Legg også den direkte veien til i diagrammet. En reservemarshrute, et unntak for delt tunnel eller en proxy-omvei kan få en side til å lastes mens den stille hopper over kjeden du ville teste, og en slik suksess villeder mer enn feilen.
Rekkefølgen avgjør hva som kan bæres
Tor bærer TCP-strømmer gjennom SOCKS-grensesnittet sitt, og en klient som ber proxyen slå opp vertsnavnet, holder oppslaget inne i kretsen. UDP reiser ikke slik i vanlige konfigurasjoner, derfor kan en WireGuard-tunnel ikke bygges inn i Tor uten et ekstra TCP-relé i midten.
OpenVPN kan tvinges til TCP, så det oppsettet er i det minste beskrivelig. Det er også langsommere og mer skjørt, og feilmodusen når det brytes ser identisk ut med en blokkert port. Regn med å bruke lengre tid på å skille de to enn på å reparere noen av dem.
Oppslaget er den andre halvdelen. Med --socks5-hostname slår proxyen opp målet, mens vanlig --socks5 først spør den lokale resolveren og lekker navnet ut av kretsen. Nettopp det ene flagget avgjør om navneoppslaget hører til kjeden eller til tilbyderen din.
| 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 |
Å finne den første brutte grensen
Test trinnene i den rekkefølgen pakkene reiser, med ufarlige forespørsler, og stopp ved det første som feiler. Noter hvilken kommando som kjørte først, fordi rekkefølgen er en del av beviset. To kommandoer skiller en død krets fra en død utgang:
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ørsel i det hele tatt fullføres gjennom SOCKS-proxyen, og den andre viser adressen nettverket presenterer akkurat nå. Hvis den første feiler og den andre lykkes, sitter problemet ved eller før Tor-klienten. Hvis begge lykkes og nettleseren fortsatt feiler, bruker applikasjonen en annen vei enn skallet.
En side med offentlig IP beskriver også bare den siste synlige utgangen. Den kan ikke si hvor mange hopp som kom før, så kombiner den med den støttede statusutskriften til hvert verktøy i stedet for å behandle ett tall som et diagram.
Når man bør slutte å legge til lag
Hvis du ikke kan si i én setning hva et lag bidrar med, fjern det. En kjede der formålet er uklart, er en kjede ingen kan feilsøke klokken tre om natten, og personverngevinsten ved et uforklart hopp er vanligvis mindre enn tilgjengeligheten du mister.
Hvis et lag virkelig fortjener plassen, test det alene først, legg så til det neste og bekreft veien igjen med de samme to kommandoene. Gjenopprett hele kjeden før vanlig bruk, og hold TLS-validering og autentisering påslått; en sertifikatadvarsel som godtas for å få en side til å lastes, er en ruteomvei, ikke en reparasjon. Skriv ned rekkefølgen du landet på mens den er fersk.
Skriv ned den rekkefølgen, inkludert resolveren som svarer på hvert trinn. En fungerende kjede du kan beskrive, overlever neste oppdatering, mens en fungerende kjede du satte sammen ved å prøve deg fram, forsvinner med den. Legg til dato og versjoner, slik at en senere feil kan sammenlignes med en kjent god tilstand i stedet for å diskuteres fra hukommelsen. Ti linjer i en tekstfil sparer en kveld med gjetting.