Tor-uitgangsrelay versus VPN-uitgangsserver: wat elk weet
Een Tor-uitgangsrelay en een VPN-uitgangsserver tonen beide één openbaar adres, maar verdelen kennis anders. Vergelijk zichtbaarheid, dekking en poortbeleid.
Beide ontwerpen verbergen je adres achter één openbaar IP, en een site die het adres afdrukt dat hij ziet kan ze niet onderscheiden. Het verschil zit in wie onderweg wat leert, hoeveel verkeer gedekt is en welke poorten mogen werken. Een Tor-uitgangsrelay is de laatste sprong van een circuit van drie relays; een VPN-uitgangsserver beëindigt je tunnel en maakt zelf de uitgaande verbinding. Hier lees je hoe ik bepaal welke een taak nodig heeft, en wat ik controleer voordat ik aanneem dat de een zich als de ander gedraagt.
Twee paden die op één adres eindigen
Tor bouwt een circuit via een wacht, een tussenrelay en een uitgang, en versleutelt de lading in lagen zodat elke relay alleen zijn eigen laag afpelt. De uitgang maakt de gewone TCP-verbinding naar de bestemming, daarom ziet de bestemming het uitgangsadres. Je client spreekt nooit rechtstreeks met de bestemming, en de wacht ziet die ook niet.
Een VPN is één tunnel naar één eindpunt. De server van de operator haalt de tunnel weg en opent de uitgaande verbinding, zodat de bestemming ook één adres ziet, dit keer dat van de operator. Het waarneembare resultaat is hetzelfde; de kennis niet. Een test die een IP afdrukt, antwoordt op welk systeem je zit en niets over de vertrouwensverdeling die werkelijk verschilt.
Wie uiteindelijk wat weet
Het VPN-eindpunt ziet het bronadres, de bestemming, de timing en het volume op één plek. Die concentratie is het ontwerp: één operator, één logoppervlak, één plek om te dagvaarden of verkeerd te configureren. Alles wat je wint komt uit vertrouwen in die partij en uit het uitgaande beleid van het eindpunt.
Tor verdeelt die kennis. De wacht kent je adres maar niet de bestemming; de uitgang kent de bestemming maar niet je adres. Een relay hoort niet beide te leren. Dat is een structurele eigenschap, geen belofte tegen een wereldwijde waarnemer, een relay die tijden correleert of een gecompromitteerd eindpunt, dus behandel het als een andere verdeling van hetzelfde risico en niet als anonimiteit die niet kan falen.
| What is known | Tor exit relay | VPN exit server |
|---|---|---|
| Your public address | Seen by the guard relay, not the exit | Seen at the endpoint |
| Final destination | Seen at the exit | Seen at the endpoint |
| Coverage | Applications configured for Tor, chiefly Tor Browser | Whatever the route policy includes |
| Plain HTTP payload | Readable at the exit | Readable at the endpoint |
Dekking is een browserbeslissing of een routebeslissing
De Tor Browser routeert zijn eigen verkeer en voegt beschermingen toe die een gewone VPN-client niet reproduceert: weerstand tegen vingerafdrukken, isolatie van de eerste partij, een vaste venstergrootte en een actie Nieuwe identiteit die de sessiestatus weggooit. Andere toepassingen gebruiken dat circuit niet tenzij ze daarvoor zijn geconfigureerd, en een systeembrede Tor-opstelling is een apart project van het installeren van de browser.
Een VPN heeft de tegenovergestelde vorm. Dekking volgt de routetabel, dus een WireGuard-profiel met AllowedIPs = 0.0.0.0/0 vangt alles en een split-tunnel-lijst vangt alleen de prefixen die hij noemt. Juist in dat mechanisme zitten ook de lekken: DNS-query's, IPv6 en WebRTC kunnen elk een pad nemen dat het routebeleid niet omvatte. Controleer van binnenuit de toepassing die faalde, niet vanaf een browsertab die misschien een andere interface gebruikt.
Poortbeleid, geblokkeerde bestemmingen en HTTPS
Een uitgangsrelay mag uitgaande poorten weigeren, en het standaardbeleid wijst een lijst misbruikgevoelige poorten af, met SMTP-poort 25 daarbij. Een mailclient die via Tor is geconfigureerd faalt daarom bij de uitgang, wat op een netwerkstoring lijkt en het niet is. Operators die een relay draaien stellen dit expliciet in:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Bestemmingen blokkeren ook, en ze blokkeren de twee systemen verschillend. Tor-uitgangsadressen zijn openbaar, dus een site kan de hele lijst weigeren; VPN-eindpunten zitten in datacenterbereiken die even achteloos worden geweigerd. Als een pagina faalt, scheid dan de drie kandidaten voordat je iets verandert: uitgangs- of uitgaand beleid, een bestemming die de bron weigert, of een captive portal die het eerste verzoek kaapt.
Geen van beide systemen vervangt transportversleuteling. Gewone HTTP is leesbaar bij de uitgangsrelay en bij het VPN-eindpunt, dus houd HTTPS aan en lees de certificaatwaarschuwing in plaats van hem weg te klikken. Twee controles beslechten de routevraag snel: curl -s https://check.torproject.org/api/ip geeft IsTor terug wanneer het verzoek door een circuit ging, en curl -s https://ifconfig.me toont het uitgaande adres dat een VPN zou presenteren. Beide draaien vertelt je welk pad de shell echt gebruikt.
Gebruik het ene niet als het andere
Het adres van een uitgangsrelay is geen VPN-profiel. Een OpenVPN- of WireGuard-client op een relay op poort 443 richten maakt geen tunnel, omdat daar geen VPN-dienst luistert; de relay is een sprong in iemands anders circuit. Andersom is een VPN-eindpunt geen ingangspunt voor Tor, en de bridge-instellingen van de Tor Browser zijn geen plek om een hostnaam van een commerciële VPN te plakken. Als je Tor over een VPN draait, ziet de wacht het VPN-adres in plaats van het jouwe, wat de verdeling verandert zonder de twee rollen samen te voegen.
Beantwoord voordat je kiest vier vragen in volgorde: wie beheert het eindpunt en wat bewaart het, wat dekt het gereedschap op dit apparaat, welke poorten en bestemmingen staat het uitgaande beleid toe, en wat voegt de toepassing toe buiten het netwerkpad. Een taak die gewone netwerktoegang voor veel programma's nodig heeft, wil een VPN. Een taak die de beschermingen op browserniveau en het circuitmodel nodig heeft, wil de Tor Browser, up-to-date gehouden. Als het antwoord «beide» is, draai ze in een bewuste volgorde en schrijf op welk adres elke kant ziet.