Tor oder VPN: Entscheiden Sie danach, wem jeder Weg Sie vertrauen lässt
Ein VPN bündelt Ihr Vertrauen bei einem Betreiber; Tor verteilt es auf Relays. Entscheiden Sie nach Abdeckung, danach, wer Sie mit einer Website verknüpfen kann, und nach dem, was Sie überprüfen können.
Die Wahl zwischen Tor und einem VPN läuft darauf hinaus, welcher Seite Sie zutrauen können, beide Enden einer Verbindung zu sehen. Ein VPN bündelt diesen Blick bei einem Betreiber, den Sie ausgewählt haben. Tor verteilt ihn auf Relays, sodass kein einzelnes Relay erfahren soll, wer Sie sind und was Sie abgerufen haben.
Keine der beiden Anordnungen macht Sie für sich genommen anonym. Wählen Sie diejenige, deren verbleibendes Vertrauen Sie laut benennen können, und schließen Sie dann die Teile, die sie offen lässt.
Zählen Sie, wer Sie mit einem Ziel verknüpfen kann
Bei einem VPN erreicht jeder abgedeckte Datenstrom den Ausgang des Betreibers, bevor er das Ziel erreicht. Dieser Betreiber sieht zwangsläufig Ihre Quelladresse und, für alles, was nicht durch ihn verschlüsselt ist, das von Ihnen angeforderte Ziel. TLS hält Seiteninhalte aus diesem Blick heraus, lässt aber während des Verbindungsaufbaus normalerweise den Hostnamen sichtbar. Eine Partei kann Sie daher mit einer Website verknüpfen, und diese Verknüpfung ist genau das Vertrauen, das Sie gewähren.
Tor trennt diese Hälften auf drei Relays auf: einen Guard, der Ihre Adresse kennt, aber nicht Ihr Ziel, ein mittleres Relay, das keines der beiden Enden kennt, und einen Ausgang, der das Ziel kennt, aber nicht Sie. Das Design setzt voraus, dass kein einzelnes Relay beide Fakten zusammenführt, was eine schwächere und nützlichere Annahme ist, als einem Unternehmen zu vertrauen. Es setzt nicht voraus, dass Relays ehrlich sind, und es besiegt keinen Beobachter, der beide Enden des Wegs sieht.
Beide Designs teilen einen schwachen Punkt, und er liegt am Ziel. Wenn Sie sich anmelden, verknüpft der Dienst diese Sitzung mit Ihrem Konto, welchen Weg die Pakete auch genommen haben. Routing ändert, woher eine Anfrage scheinbar kommt, nicht, was die Seite Sie zu liefern bittet.
Abdeckung zählt mehr als das Routing-Diagramm
Ein VPN routet auf der Netzwerkschicht, sodass jede Anwendung auf dem Gerät den Tunnel erbt, sofern Sie sie nicht bewusst ausnehmen. Diese Breite ist der Grund, warum es gleichzeitig für einen Mail-Client, einen Paketmanager und einen Browser funktioniert.
Tor Browser ist ein Paket, und seine Schutzmaßnahmen leben überwiegend im Browser: ein einheitlicher Fingerabdruck, Isolation zwischen Websites und Skripte, die durch eine Sicherheitsstufe begrenzt werden statt durch die von Ihnen installierten Erweiterungen. Chrome auf einen SOCKS-Port zu zeigen kauft das Routing ohne all das, was eine häufige Quelle falschen Selbstvertrauens ist.
Der Rest des Desktops bleibt unberührt. Ein Synchronisierungs-Client, ein Updater oder ein heruntergeladenes Dokument, das in einem anderen Programm geöffnet wird, verbindet sich so, wie dieses Programm konfiguriert ist, und nichts davon passiert den SOCKS-Listener, sofern Sie es dort nicht einrichten. Zählen Sie die Anwendungen auf, die mit dem Netzwerk sprechen, und fragen Sie dann, welche davon das gewählte Werkzeug tatsächlich abdeckt. Abdeckung ist eine Eigenschaft Ihrer Konfiguration, nicht Ihrer Absicht.
Wählen Sie mit drei Bedingungen
Die Entscheidung löst sich meist an drei Fragen: Kommt der Verkehr aus einer Anwendung oder vom gesamten Gerät, darf das Ziel Ihre Adresse nicht identifizieren können, und müssen Sie ein privates Netz erreichen? Beantworten Sie sie in dieser Reihenfolge, und das Werkzeug wählt sich meist selbst.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
Wo zwei Anforderungen kollidieren, wägen Sie ab, welche Sie durchsetzen können. Ein Gerätetunnel mit einer undichten Ausnahmeliste ist schlechter als eine reine Browser-Route, die Sie nachweisen können.
Die Überprüfung ist für beide Wege billig, und sie sollte geschehen, bevor Sie sich auf einen von beiden verlassen:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Ein falsches Ergebnis des ersten Befehls bedeutet, dass die Anfrage den Circuit verlassen hat, und das ist der Fehler, den es früh zu fangen gilt. Vergleichen Sie den zweiten mit der Adresse, die Ihr Anbieter zugewiesen hat, nicht mit der, die Sie von letzter Woche erinnern.
Was keine der beiden Optionen repariert
Anwendungsverschlüsselung erledigt weiterhin Arbeit, die keine Route leistet. Reines HTTP, das ein Privatsphärennetz durchquert, bleibt am Ausgang lesbar, und HTTPS bleibt das Einzige, was die Nutzlast von Ende zu Ende schützt. TLS sagt auch nichts über den Hostnamen, den Sie eingegeben haben, weshalb das Ziel für jeden sichtbar bleibt, der den Weg beendet.
Konten identifizieren Sie, und keine Routing-Wahl ändert das: Der Dienst weiß, wer sich angemeldet hat, unabhängig von der Adresse im Header. Korrelation durch einen Beobachter, der genug vom Netz sieht, die Kompromittierung Ihres eigenen Geräts und alles, was Sie in ein Formular tippen, überstehen beide Designs. Behandeln Sie beide Werkzeuge als Wege, Vertrauen zu verschieben, nicht als Wege, es zu löschen.
Beginnen Sie mit der Standardkonfiguration, die jedes Projekt dokumentiert, bestätigen Sie die Route mit den beiden Befehlen oben, und erwägen Sie erst dann, ein VPN unter Tor zu stapeln. Das Verschachteln ist eine Konfiguration mit eigenen Fehlerarten, kein kostenloses Upgrade.