VPN gennem Tor: transportkontrollen kommer først

Tor-først betyder, at VPN-klienten sidder bag en SOCKS-proxy, så tunnelen selv bygges gennem Tor, og applikationstrafik forlader VPN-endepunktet. Det er én bestemt rækkefølge, og det er ikke det, de fleste bygger. At åbne Tor Browser ved siden af en normal VPN-klient tvinger ikke nogen af de to programmer til at bruge den andens vej.

Gå gennem kontrollerne i rækkefølge. Hver af dem afgør, om den næste er værd at starte.

Hvilken rækkefølge bygger du egentlig

To rækkefølger blandes sammen i samme samtale. Tor først betyder, at VPN-klienten når sin server gennem en SOCKS-proxy, så tunnelen bygges oven på Tor. VPN først betyder, at Tor-trafik forlader gennem tunnelen, hvilket de fleste bygger ved et uheld og derefter beskriver som den anden. Den første samler videresendelsesgrænsen hos VPN-operatøren, den anden samler den ved Tor-indgangen og -udgangen. Ingen af dem er det, du får ved at have begge programmer åbne på én gang.

Skriv ned, hvilken rækkefølge opgaven kræver, før du konfigurerer noget, fordi de to kræver forskellige softwareindstillinger og fejler forskellige steder. En fejlmærket rækkefølge sender dig til at fejlsøge det forkerte lag i en time. Alt nedenfor forudsætter Tor først.

Kontroller transporten før alt andet

Tors SOCKS-grænseflade bærer TCP-strømme og giver ikke en generel UDP-forbindelse. En VPN, hvis transport er UDP, kan ikke behandle den proxy som en almindelig netværksgrænseflade, og ingen klientindstilling ændrer, hvad proxyen er villig til at videresende. WireGuard i sin sædvanlige form er det oplagte offer. En OpenVPN-profil i TCP-tilstand er den almindelige løsning, og den skal stadig udtrykkeligt have besked om at bruge proxyen.

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

Bekræft, at proxyen lytter og kan bære én almindelig HTTPS-anmodning, før du fejlsøger en tunnel gennem den. Hvis den almindelige anmodning fejler, vil VPN-klienten aldrig lykkes, og dens logfiler vil ikke fortælle dig hvorfor.

Omskriv observatørkortet

Tor-indgangen kan se den kilde, der forbinder til Tor, medmindre noget tidligere har ændret den, så det hop lærer din adresse. VPN-udbyderen modtager en forbindelse, der ankommer fra Tor-siden, men kan stadig kende en konto, en betalingspost eller en adgangsoplysning, du sendte inde i tunnelen. Destinationer, der nås gennem VPN'en, ser dens udgang i stedet for Tors udgang, og det samler den endelige videresendelsesgrænse hos én operatør.

Den genskaber heller ikke en distribueret vej til hver destination. Tor Browser bygger et frisk kredsløb pr. websted; en VPN båret over Tor bygger én tunnel, og hvert websted bag den deler det endepunkt. Behandl forskellen som et designfaktum, ikke som en begrænsning, der skal tunes væk.

Tæl fejllagene, når det går i stykker

Et ødelagt opsætning har mindst fire uafhængige lag: SOCKS-forbindelsen, TLS-håndtrykket med VPN-serveren, selve VPN-håndtrykket og derefter routing eller navneopløsning inde i tunnelen. Hvert fejler med et andet symptom, og hvert kræver en anden reparation. At lempe certifikatkontroller, fordi tunnelen ikke kommer op, er den klassiske fejldiagnose, og den forvandler et transportproblem til et sikkerhedsproblem.

Log det første lag, der fejler, og stop der. En proxyafvisning og en afvist nøgle er ikke variationer af den samme hændelse.

Stop, hvis trusselsmodellen kræver Tor Browsers forsvar

At route vilkårlige programmer gennem en VPN båret af Tor giver ikke de programmer Tor Browsers fingeraftryks- og isoleringsfunktioner. Deres konti, identifikatorer og egen netværksadfærd forbliver relevante, og en tunnel normaliserer ingen af dem. Hvis målet er en browser, der smelter sammen med andre brugere, leverer denne rækkefølge det ikke.

Tor Project selv advarer mod kombinationer, som brugere ikke kan konfigurere korrekt, og denne gælder for de fleste. Det er et bevidst design til en smal trusselsmodel, ikke en genvej til anonym trafik på hele enheden.