VPN før Tor: hvad rækkefølgen egentlig ændrer

At tilslutte VPN'en først giver en bestemt kæde: enhed, VPN-endepunkt, Tor-indgang, Tor-kredsløb, destination. Dit lokale netværk ser én krypteret forbindelse til VPN'en, og Tor-indgangsknudepunktet ser VPN-udgangen som den umiddelbare kilde i stedet for din udbyderadresse. VPN-operatøren ser til gengæld forbindelser mod Tor-indgangsinfrastruktur og kan udlede Tor-brug ud fra destinationerne. Hver observatør mister noget og vinder noget, og derfor er rækkefølgen en byttehandel snarere end en opgradering.

Intet i den kæde ændrer, hvad webstedet lærer fra din konto, cookies eller indtastede oplysninger.

Hvad rækkefølgen ændrer

Det lokale netværk og udbyderen mister direkte indsigt i din Tor-trafik, fordi det første hop nu er en krypteret tunnel til en udbyder. Tor-indgangsvagten mister din hjemadresse og ser VPN-udgangen. VPN-udbyderen får de metadata, som din udbyder tidligere havde: hvilke adresser du kontakter, på hvilke tidspunkter, og hvor meget data der flyttes.

Efter indgangsvagten opfører kredsløbet sig som før. Relæerne adskiller stadig rollerne indgang, midte og udgang, og VPN'en ser ikke det endelige indhold mere, end din udbyder gjorde.

Bekræft den rute, der faktisk bruges

Opdelt tunnellering er den sædvanlige grund til, at den tilsigtede kæde ikke er den virkelige.Hvis Tor Browser er udelukket fra tunnelen, eller en anden profil ruter anderledes, ser indgangsvagten igen udbyderadressen, mens grænsefladen stadig ser tilsluttet ud. Kontroller ruten og den observerede udgang 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-anmodningen via port 9150 besvares af Tor Browsers egen klient, så et svar på IsTor true bekræfter browserens kredsløb, ikke at alle andre programmer bruger det. Resolverens output er værd at registrere, fordi DNS kan forlade via en rute, som tunnelen ikke dækker. Gem begge output med et tidsstempel. De er grundlaget for den næste sammenligning.

Sammenlign med en direkte anmodning fra en normal terminal: hvis den også rapporterer Tor, omdirigerer noget andet trafikken, og kæden er ikke, hvad designet forudsatte.

Se, hvad der sker, når tunnelen falder

En klient, der stille falder tilbage til den lokale grænseflade, ændrer den kilde, indgangsvagten ser, og brugeren er normalt uvidende, fordi siden stadig indlæses. Det er den fejl, der er værd at teste, ikke den glade vej. Afbryd tunnelen med vilje, og se, om Tor-trafikken stopper eller fortsætter ubeskyttet.

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

Firewallregler, der blokerer udgående trafik uden for tunnelen, er den eneste pålidelige reservekontrol, og de skal dække både browserens SOCKS-klient og ethvert andet program, du bekymrer dig om. En browserudvidelse er ikke en enheds-VPN og påvirker ikke andre programmer eller eksterne iagttagere.

Beslut, om det ekstra lag fortjener sin tillid

Tor Project fraråder at stable en VPN under Tor, medmindre du selv kan vurdere opsætningen. Deres angivne grund er den ekstra afhængighed: en ekstra part, en ekstra konto og en ekstra fejltilstand. Hvis målet er at forhindre din udbyder i at se, at du bruger Tor, henvender VPN'en sig til netop den observatør. Hvis målet er stærkere anonymitet mod en global observatør, leverer VPN'en det ikke.

Den omvendte rækkefølge findes også, og navnene kan ikke byttes om:Tor over VPN og VPN over Tor beskriver forskellige tillidsforhold og forskellig fejlopførsel. Læs sammenligningen, før du blander dem.

Skriv ned, hvilken observatør du prøver at flytte, og bekræft derefter, at den virkelige rute matcher designet, og bekræft derefter fejlopførslen. Hvis de tre svar ikke retfærdiggør den ekstra konto og konfiguration, har den dokumenterede Tor Browser-opsætning færre dele, der kan gå galt.