Tor-Ausgangsrelay vs. VPN-Ausgangsserver: Was jede Seite weiß

Beide Konstruktionen verbergen deine Adresse hinter einer einzigen öffentlichen IP, und eine Website, die die Adresse ausgibt, die sie sieht, kann sie nicht unterscheiden. Der Unterschied liegt darin, wer unterwegs was erfährt, wie viel Verkehr abgedeckt ist und welche Ports zulässig sind. Ein Tor-Ausgangsrelay ist die letzte Station eines Circuits aus drei Relays; ein VPN-Ausgangsserver beendet deinen Tunnel und stellt die ausgehende Verbindung selbst her. Hier ist, wie ich entscheide, welches System eine Aufgabe braucht, und was ich prüfe, bevor ich annehme, dass sich das eine wie das andere verhält.

Zwei Wege, die an einer Adresse enden

Tor baut einen Circuit über einen Guard, ein Middle-Relay und einen Exit auf und verschlüsselt die Nutzdaten in Schichten, sodass jedes Relay nur seine eigene Schicht abzieht. Der Exit stellt die gewöhnliche TCP-Verbindung zum Ziel her, weshalb das Ziel die Exit-Adresse sieht. Dein Client spricht nie direkt mit dem Ziel, und der Guard sieht es ebenfalls nie.

Ein VPN ist ein Tunnel zu einem Endpunkt. Der Server des Betreibers entfernt den Tunnel und öffnet die ausgehende Verbindung, sodass das Ziel ebenfalls eine einzelne Adresse sieht, diesmal die des Betreibers. Das beobachtbare Ergebnis ist dasselbe; das Wissen nicht. Ein Test, der eine IP ausgibt, beantwortet, in welchem System du unterwegs bist, und nichts über die Verteilung von Vertrauen, die sich tatsächlich unterscheidet.

Wer am Ende was weiß

Der VPN-Endpunkt sieht die Quelladresse, das Ziel, den Zeitpunkt und das Volumen an einer Stelle. Diese Bündelung ist das Design: ein Betreiber, eine Protokollfläche, eine Stelle für Auskunftsersuchen oder Fehlkonfigurationen. Alles, was du gewinnst, beruht auf dem Vertrauen in diese Partei und auf der Egress-Richtlinie des Endpunkts.

Tor teilt dieses Wissen auf. Der Guard kennt deine Adresse, aber nicht das Ziel; der Exit kennt das Ziel, aber nicht deine Adresse. Ein Relay soll nicht beides erfahren. Das ist eine strukturelle Eigenschaft, kein Versprechen gegen einen globalen Beobachter, ein Relay, das Zeitpunkte korreliert, oder einen kompromittierten Endpunkt; behandle es daher als andere Verteilung desselben Risikos und nicht als Anonymität, die nicht versagen kann.

Abdeckung ist eine Browser- oder eine Routing-Entscheidung

Der Tor Browser leitet seinen eigenen Verkehr und ergänzt Schutzmaßnahmen, die ein gewöhnlicher VPN-Client nicht nachbildet: Widerstand gegen Fingerprinting, First-Party-Isolation, eine feste Fenstergröße und eine Aktion „Neue Identität“, die den Sitzungszustand verwirft. Andere Anwendungen nutzen diesen Circuit nicht, sofern sie nicht dafür konfiguriert sind, und ein systemweites Tor-Setup ist ein eigenes Projekt, getrennt von der Installation des Browsers.

Ein VPN ist umgekehrt aufgebaut. Die Abdeckung folgt der Routingtabelle, sodass ein WireGuard-Profil mit AllowedIPs = 0.0.0.0/0 alles erfasst und eine Split-Tunnel-Liste nur die darin genannten Präfixe. Genau dort sitzen auch die Leaks: DNS-Abfragen, IPv6 und WebRTC können jeweils einen Pfad nehmen, den die Routing-Richtlinie nicht umfasst. Prüfe aus der Anwendung heraus, die ausgefallen ist, nicht aus einem Browser-Tab, das möglicherweise eine andere Schnittstelle verwendet.

Portrichtlinie, blockierte Ziele und HTTPS

Ein Exit-Relay darf ausgehende Ports ablehnen, und die Standardrichtlinie weist eine Liste missbrauchsanfälliger Ports zurück, darunter SMTP-Port 25. Ein über Tor konfigurierter Mail-Client scheitert daher am Exit, was wie ein Netzwerkfehler aussieht und keiner ist. Betreiber eines Relays legen das ausdrücklich fest:

# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25

Auch Ziele blockieren, und sie blockieren die beiden Systeme unterschiedlich. Tor-Exit-Adressen sind veröffentlicht, sodass eine Website die ganze Liste ablehnen kann; VPN-Endpunkte liegen in Rechenzentrumsbereichen, die ebenso beiläufig abgelehnt werden. Wenn eine Seite ausfällt, trenne vor jeder Änderung die drei Kandidaten: Exit- oder Egress-Richtlinie, ein Ziel, das die Quelle ablehnt, oder ein Captive Portal, das die erste Anfrage abfängt.

Keines der beiden Systeme ersetzt die Transportverschlüsselung. Reines HTTP ist am Exit-Relay wie am VPN-Endpunkt lesbar, also lass HTTPS an und lies die Zertifikatswarnung, statt sie wegzuklicken. Zwei Prüfungen klären die Routing-Frage schnell: curl -s https://check.torproject.org/api/ip gibt IsTor zurück, wenn die Anfrage durch einen Circuit lief, und curl -s https://ifconfig.me zeigt die Egress-Adresse, die ein VPN präsentieren würde. Beide auszuführen sagt dir, welchen Pfad die Shell tatsächlich nutzt.

Verwechsle die beiden nicht

Die Adresse eines Exit-Relays ist kein VPN-Profil. Einen OpenVPN- oder WireGuard-Client auf ein Relay an Port 443 zu richten, erzeugt keinen Tunnel, weil dort kein VPN-Dienst lauscht; das Relay ist eine Station im Circuit eines anderen. Umgekehrt ist ein VPN-Endpunkt kein Einstiegspunkt für Tor, und die Bridge-Einstellungen des Tor Browser sind kein Ort, um einen kommerziellen VPN-Hostnamen einzufügen. Wenn du Tor über ein VPN betreibst, sieht der Guard die VPN-Adresse statt deiner, was die Aufteilung ändert, ohne die beiden Rollen zu verschmelzen.

Beantworte vor der Wahl vier Fragen in dieser Reihenfolge: Wer betreibt den Endpunkt und was behält er, was deckt das Werkzeug auf diesem Gerät ab, welche Ports und Ziele erlaubt die Egress-Richtlinie, und was fügt die Anwendung über den Netzwerkpfad hinaus hinzu. Eine Aufgabe, die für viele Programme gewöhnlichen Netzzugang braucht, will ein VPN. Eine Aufgabe, die die Schutzmaßnahmen auf Browser-Ebene und das Circuit-Modell braucht, will den Tor Browser, aktuell gehalten. Wenn die Antwort „beides“ lautet, betreibe sie in einer bewussten Reihenfolge und notiere, welche Adresse jede Seite sieht.