VPN før Tor: hva rekkefølgen egentlig endrer

Å koble til VPN først gir en bestemt kjede: enhet, VPN-endepunkt, Tor-inngang, Tor-krets, destinasjon. Ditt lokale nettverk ser én kryptert forbindelse til VPN-en, og Tor-inngangsknuten ser VPN-utgangen som umiddelbar kilde i stedet for adressen til leverandøren din. VPN-operatøren ser på sin side forbindelser mot Tor-inngangsinfrastruktur og kan utlede Tor-bruk fra destinasjonene. Hver observatør taper noe og vinner noe, og derfor er rekkefølgen en byttehandel og ikke en oppgradering.

Ingenting i den kjeden endrer hva nettstedet lærer fra kontoen din, informasjonskapsler eller innskrevne detaljer.

Hva rekkefølgen endrer

Det lokale nettverket og internettleverandøren mister direkte innsyn i Tor-trafikken din, fordi første hopp nå er en kryptert tunnel til en leverandør. Tor-inngangsvakten mister hjemadressen din og ser VPN-utgangen. VPN-leverandøren får metadataene som internettleverandøren din tidligere hadde: hvilke adresser du kontakter, til hvilke tider og hvor mye data som flyttes.

Forbi inngangsvakten oppfører kretsen seg som før. Reléene skiller fortsatt rollene inngang, midten og utgang, og VPN-en ser ikke det endelige innholdet mer enn internettleverandøren din gjorde.

Bekreft ruten som faktisk brukes

Delt tunnellering er den vanlige grunnen til at den tiltenkte kjeden ikke er den virkelige.Hvis Tor Browser er utelukket fra tunnelen, eller en andre profil ruter annerledes, ser inngangsvakten leverandøradressen igjen mens grensesnittet fortsatt ser tilkoblet ut. Kontroller ruten og den observerte utgangen i stedet for ikonet.

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

SOCKS-forespørselen via port 9150 besvares av Tor Browsers egen klient, så et svar på IsTor true bekrefter nettleserens krets, ikke at alle andre programmer bruker den. Resolverens utdata er verdt å registrere fordi DNS kan gå ut via en rute tunnelen ikke dekker. Ta vare på begge utdataene med tidsstempel. De er grunnlaget for den neste sammenligningen.

Sammenlign med en direkte forespørsel fra en vanlig terminal: hvis den også rapporterer Tor, omdirigerer noe annet trafikken, og kjeden er ikke det designet forutsatte.

Se hva som skjer når tunnelen faller

En klient som stille faller tilbake til det lokale grensesnittet endrer kilden inngangsvakten ser, og brukeren vet det vanligvis ikke fordi siden fortsatt lastes. Det er den feilen som er verdt å teste, ikke den lykkelige veien. Koble fra tunnelen med vilje og se om Tor-trafikken stopper eller fortsetter ubeskyttet.

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

Brannmurregler som blokkerer utgående trafikk utenfor tunnelen er den eneste pålitelige reservekontrollen, og de må dekke både nettleserens SOCKS-klient og ethvert annet program du bryr deg om. En nettleserutvidelse er ikke en enhets-VPN og påvirker ikke andre programmer eller eksterne observatører.

Bestem om det ekstra laget fortjener tilliten

Tor Project fraråder å stable en VPN under Tor med mindre du selv kan vurdere oppsettet. Den oppgitte grunnen er den ekstra avhengigheten: en annen part, en annen konto og en annen feilmodus. Hvis målet er å hindre internettleverandøren din i å se at du bruker Tor, retter VPN-en seg mot nettopp den observatøren. Hvis målet er sterkere anonymitet mot en global observatør, leverer ikke VPN-en det.

Den omvendte rekkefølgen finnes også, og navnene er ikke utskiftbare:Tor over VPN og VPN over Tor beskriver forskjellige tillitsforhold og forskjellig feilatferd. Les sammenligningen før du blander dem.

Skriv ned hvilken observatør du prøver å flytte, bekreft deretter at den virkelige ruten samsvarer med designet, og bekreft deretter feilatferden. Hvis de tre svarene ikke rettferdiggjør den ekstra kontoen og konfigurasjonen, har det dokumenterte Tor Browser-oppsettet færre deler som kan gå galt.