Eerst de VPN verbinden levert een specifieke keten op: apparaat, VPN-eindpunt, Tor-ingang, Tor-circuit, bestemming. Je lokale netwerk ziet één versleutelde verbinding naar de VPN, en het Tor-ingangsknooppunt ziet de VPN-uitgang als de directe bron in plaats van het adres van je provider. De VPN-operator ziet op zijn beurt verbindingen naar de Tor-ingangsinfrastructuur en kan uit de bestemmingen Tor-gebruik afleiden. Elke waarnemer verliest iets en wint iets, daarom is de volgorde een ruil en geen verbetering.

Niets in die keten verandert wat de website leert uit je account, cookies of getypte gegevens.

Wat de volgorde verandert

Het lokale netwerk en de ISP verliezen direct zicht op je Tor-verkeer, omdat de eerste hop nu een versleutelde tunnel naar een provider is. De Tor-ingangswachter verliest je thuisadres en ziet de VPN-uitgang. De VPN-provider krijgt de metadata die je ISP eerder had: welke adressen je contacteert, op welke tijden en hoeveel data er beweegt.

Voorbij de ingangswachter gedraagt het circuit zich zoals voorheen. Relays scheiden nog steeds de rollen van ingang, midden en uitgang, en de VPN ziet de uiteindelijke inhoud niet meer dan je ISP.

Bevestig de route die werkelijk wordt gebruikt

Split-tunneling is de gebruikelijke reden dat de bedoelde keten niet de echte is.Als Tor Browser van de tunnel is uitgesloten, of een tweede profiel routeert anders, ziet de ingangswachter weer het provideradres terwijl de interface nog verbonden lijkt. Controleer de route en de waargenomen uitgang in plaats van het pictogram.

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'

Het SOCKS-verzoek via poort 9150 wordt beantwoord door de eigen client van Tor Browser, dus een antwoord IsTor true bevestigt het circuit van de browser, niet dat elk ander programma het gebruikt. De uitvoer van de resolver is het noteren waard, omdat DNS via een route kan vertrekken die de tunnel niet dekt. Bewaar beide uitvoer met een tijdstempel. Ze zijn de basislijn voor de volgende vergelijking.

Vergelijk met een rechtstreeks verzoek vanuit een normale terminal: als dat ook Tor meldt, leidt iets anders het verkeer om en is de keten niet wat het ontwerp aannam.

Let op wat er gebeurt als de tunnel wegvalt

Een client die stil terugvalt op de lokale interface verandert de bron die de ingangswachter ziet, en de gebruiker weet dat meestal niet omdat de pagina nog laadt. Dat is de fout die het testen waard is, niet het gelukkige pad. Verbreek de tunnel bewust en kijk of Tor-verkeer stopt of onbeschermd doorgaat.

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

Firewallregels die uitgaand verkeer buiten de tunnel blokkeren zijn de enige betrouwbare terugvalcontrole, en ze moeten zowel de SOCKS-client van de browser als elk ander programma dat je belangrijk vindt dekken. Een browserextensie is geen apparaat-VPN en beïnvloedt andere programma's of externe waarnemers niet.

Bepaal of de extra laag zijn vertrouwen verdient

Het Tor Project raadt af een VPN onder Tor te stapelen, tenzij je de opzet zelf kunt beoordelen. Hun genoemde reden is de extra afhankelijkheid: nog een partij, nog een account en nog een faalmodus. Als het doel is je ISP te laten zien dat je Tor gebruikt te voorkomen, richt de VPN zich precies op die waarnemer. Als het doel sterkere anonimiteit tegen een wereldwijde waarnemer is, levert de VPN die niet.

De omgekeerde volgorde bestaat ook, en de namen zijn niet uitwisselbaar:Tor over VPN en VPN over Tor beschrijven verschillende vertrouwensrelaties en verschillend faalgedrag. Lees de vergelijking voordat je ze mengt.

Schrijf op welke waarnemer je probeert te verschuiven, bevestig dan dat de echte route bij het ontwerp past, en bevestig dan het faalgedrag. Als die drie antwoorden het extra account en de configuratie niet rechtvaardigen, heeft de gedocumenteerde Tor Browser-opzet minder onderdelen die fout kunnen gaan.

Gerelateerde artikelen