VPN gjennom Tor: transportkontrollen kommer først

Tor-først betyr at VPN-klienten sitter bak en SOCKS-proxy, slik at tunnelen selv bygges gjennom Tor og applikasjonstrafikk forlater VPN-endepunktet. Det er én bestemt rekkefølge, og det er ikke det de fleste bygger. Å åpne Tor Browser ved siden av en vanlig VPN-klient tvinger ingen av de to programmene til å bruke den andres vei.

Gå gjennom kontrollene i rekkefølge. Hver av dem avgjør om den neste er verdt å starte.

Hvilken rekkefølge bygger du egentlig

To rekkefølger blandes i samme samtale. Tor først betyr at VPN-klienten når serveren sin gjennom en SOCKS-proxy, slik at tunnelen bygges oppå Tor. VPN først betyr at Tor-trafikk forlater gjennom tunnelen, noe de fleste bygger ved et uhell og deretter beskriver som den andre. Den første samler videresendingsgrensen hos VPN-operatøren, den andre samler den ved Tor-inngangen og -utgangen. Ingen av dem er det du får ved å ha begge programmene åpne samtidig.

Skriv ned hvilken rekkefølge oppgaven trenger, før du konfigurerer noe, fordi de to krever ulike programvareinnstillinger og feiler på ulike steder. En feilmerket rekkefølge sender deg til å feilsøke feil lag i en time. Alt nedenfor forutsetter Tor først.

Kontroller transporten før alt annet

Tors SOCKS-grensesnitt bærer TCP-strømmer og gir ikke en generell UDP-tilknytning. En VPN der transporten er UDP kan ikke behandle den proxyen som et vanlig nettverksgrensesnitt, og ingen klientinnstilling endrer hva proxyen er villig til å videresende. WireGuard i sin vanlige form er det åpenbare offeret. En OpenVPN-profil i TCP-modus er den vanlige løsningen, og den må fortsatt få beskjed uttrykkelig om å bruke proxyen.

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

Bekreft at proxyen lytter og kan bære én vanlig HTTPS-forespørsel før du feilsøker en tunnel gjennom den. Hvis den vanlige forespørselen feiler, vil VPN-klienten aldri lykkes, og loggene dens vil ikke fortelle deg hvorfor.

Skriv om observatørkartet

Tor-inngangen kan se kilden som kobler til Tor med mindre noe tidligere har endret den, så det hoppet lærer adressen din. VPN-leverandøren mottar en tilkobling som kommer fra Tor-siden, men kan fortsatt kjenne en konto, en betalingspost eller en legitimasjon du sendte inne i tunnelen. Destinasjoner som nås gjennom VPN-en, ser dens utgang i stedet for Tors utgang, og det samler den endelige videresendingsgrensen hos én operatør.

Den gjenoppretter heller ikke en distribuert vei til hver destinasjon. Tor Browser bygger en fersk krets per nettsted; en VPN båret over Tor bygger én tunnel, og hvert nettsted bak den deler det endepunktet. Behandle forskjellen som et designfaktum, ikke som en begrensning som skal tunes bort.

Tell feillagene når det ryker

Et ødelagt oppsett har minst fire uavhengige lag: SOCKS-tilkoblingen, TLS-håndtrykket med VPN-serveren, selve VPN-håndtrykket og deretter ruting eller navneoppslag inne i tunnelen. Hvert feiler med et annet symptom, og hvert trenger en annen reparasjon. Å lempe på sertifikatkontrollene fordi tunnelen ikke kommer opp, er den klassiske feildiagnosen, og den gjør et transportproblem om til et sikkerhetsproblem.

Logg det første laget som feiler, og stopp der. En proxyavvisning og en avvist nøkkel er ikke variasjoner av samme hendelse.

Stopp hvis trusselmodellen trenger Tor Browsers forsvar

Å rute vilkårlige applikasjoner gjennom en VPN båret av Tor gir ikke disse applikasjonene fingeravtrykk- og isolasjonsfunksjonene til Tor Browser. Kontoene, identifikatorene og deres egen nettverksatferd forblir relevante, og en tunnel normaliserer ingen av dem. Hvis målet er en nettleser som smelter sammen med andre brukere, leverer ikke denne rekkefølgen det.

Tor Project selv advarer mot kombinasjoner som brukere ikke kan konfigurere riktig, og denne gjelder for de fleste. Det er et bevisst design for en smal trusselmodell, ikke en snarvei til anonym trafikk på hele enheten.