Tor über VPN: Wer sieht Ihre IP, und wer sieht die Tor-Nutzung?
Bei Tor über VPN sieht der Eingangs-Relay Ihren VPN-Ausgang, und Ihr Anbieter sieht einen Guard-Relay. Kehren Sie die Reihenfolge um, ändern sich beide Beobachter.
Sie verbinden den VPN-Client, warten auf den Tunnel und öffnen dann den Tor Browser, damit er einen Kanal aufbaut. Diese unscheinbare Reihenfolge entscheidet, wer was sieht. In dieser Reihenfolge begrüßt der Tor-Eingangs-Relay die Adresse Ihres VPN-Ausgangs, und Ihr VPN-Anbieter begrüßt einen öffentlichen Guard-Relay. Machen Sie es umgekehrt, und beide Beobachter ändern sich. Beide Reihenfolgen lohnen einen Durchgang, weil Client-Einstellungen die Reihenfolge still durchbrechen, von der die Leute glaubten, sie sei in Kraft, und die Prüfung, die das erwischt, in beiden Fällen dieselbe ist.
Beginnen Sie mit der Reihenfolge, nicht mit dem Produkt
Zwei Anordnungen heißen „VPN mit Tor“, und nur die erste ist üblich. Bei Tor über VPN steht der Tunnel bereits, wenn Tor startet, also schickt der tor-Prozess seine Guard-Verbindung wie jeden anderen ausgehenden Datenverkehr in den Tunnel. Bei VPN über Tor kommt zuerst Tor hoch, und die VPN-Sitzung selbst reist durch den Kanal und erreicht den Anbieter von einem Tor-Ausgang aus.
Was sich zwischen ihnen ändert, ist, welche Adresse am fernen Ende des äußersten Glieds steht. Jeder Beobachter sieht nur den vorherigen Sprung, nie den ganzen Pfad: Der Guard sieht, wer sich mit ihm verbunden hat, und der VPN-Server sieht, wer sich mit ihm verbunden hat. Tor trägt Ihre lokale Tunneladresse nicht nach außen, und es gibt kein Feld im Protokoll, in dem es das könnte.
In beiden Reihenfolgen sieht die Zielwebsite noch einen Tor-Ausgang, und keine Reihenfolge ändert, was diese Website aus Ihrer Anmeldung erfährt. Der Unterschied beschränkt sich auf die beiden Ränder.
Was der Tor-Eingangs-Relay sieht
Der Eingang, oder Guard, nimmt eine gewöhnliche TCP-Verbindung auf einem Relay-Port an und beginnt einen TLS-Handshake mit dem Client. In einem Tor-über-VPN-Aufbau ist die Quelle dieser Verbindung Ihr VPN-Ausgang. In einem Tor-zuerst-Aufbau ist es die Adresse, die Ihre Maschine benutzt hat, um das Tor-Netz zu erreichen, normalerweise Ihre Heimverbindung.
Das beantwortet die IP-Hälfte der Frage, aber nur, wenn der Tunnel die Verbindung tatsächlich getragen hat. Der Tor-Prozess erreicht den Guard über seinen eigenen Socket, und dieser Socket unterliegt nicht den Proxy-Einstellungen des Tor Browser. Der Browser spricht über SOCKS auf 9150 mit dem mitgelieferten tor-Prozess, und tor öffnet dann seine eigene Verbindung über die Routing-Tabelle des Kernels. Eine Socks5Proxy-Zeile in torrc oder ein Client-Transport ändert diesen Pfad. Sonst nichts.
Unter Linux können Sie die Antwort an der Maschine ablesen. Fragen Sie den Kernel, welche Schnittstelle er für eine beliebige öffentliche Adresse verwenden würde, und sehen Sie sich dann die lokale Adresse der bestehenden Verbindung an:
ip route get 203.0.113.10
sudo ss -tnp | grep -i torWenn die Route dev wg0 oder dev tun0 sagt und die lokale Adresse der bestehenden Verbindung die Tunneladresse ist, ist Tor innerhalb des VPN. Wenn die Route Ihre physische Schnittstelle nennt, ist es außerhalb, was auch immer die eigene Anzeige des Clients behauptet.
Was Ihr VPN-Anbieter sehen kann
Der Anbieter beendet Ihre VPN-Sitzung, also sieht er die Adressen, mit denen Sie sich verbinden. Guard-Relay-Adressen werden im öffentlichen Konsens veröffentlicht, und ihre Ports sind weithin bekannt, sodass ein Abgleich ein Listennachschlag ist und keine tiefe Paketinspektion. Ein Anbieter muss Tor nicht brechen, um zu wissen, dass eine Sitzung Tor ist.
Was er nicht sieht, ist der Rest des Kanals. Der mittlere Relay und der Ausgang werden innerhalb von Tor gewählt, und der Anbieter behandelt nur das Glied zum Guard. Seiteninhalt bleibt in TLS, das am Ausgang endet, und die Namensauflösung für Tor-Verkehr findet ebenfalls am Ausgang statt, also gibt es keine DNS-Anfrage beim Anbieter, die sich einer Destination zuordnen ließe.
Brücken mit obfs4 ändern den Nachschlag, nicht die Topologie. Eine Brückenadresse fehlt in der öffentlichen Relay-Liste, und der Verkehr wird geformt, um nicht wie Tor auszusehen, sodass ein Betreiber, der nur Adressen vergleicht, sie nicht markiert. Die Sitzung kommt weiterhin von Ihrem VPN-Client, und der Anbieter sieht weiterhin einen Endpunkt, ein Volumen und einen Zeitplan.
Fähigkeit ist keine Aufbewahrungsrichtlinie
Ein Betreiber, der eine Verbindung beobachten kann, hat nicht versprochen, sie zu behalten. Protokollierung ist eine separate Entscheidung, in einer Richtlinie festgehalten, durch die Jurisdiktion begrenzt und nur durch Belege prüfbar, denen Sie bereits vertrauen. Ein Keine-Logs-Etikett ändert die oben beschriebene Netzwerkrolle nicht.
Kontoidentität ist meist wichtiger als die Ausgangsadresse. Wenn Sie sich mit einer E-Mail-Adresse angemeldet oder mit Karte bezahlt haben, kann der Anbieter die Sitzung an Sie binden, ohne ein einziges Ziel zu protokollieren. Ausgangs-IPs zu wechseln ändert daran nichts.
Prüfen Sie die Abdeckung, bevor Sie einer der beiden Antworten vertrauen
Die meisten, die glauben, Tor über VPN zu betreiben, betreiben nur einen Teil davon. Split-Tunneling, das den Tor Browser ausschließt, ein Kill-Switch, der den Browser, aber nicht den tor-Dienst abdeckt, eine Starteinheit, die vor dem Hochfahren des Tunnels läuft, und ein IPv6-Pfad um den Tunnel herum sind die üblichen vier.
Den Statusbildschirm des Clients zu lesen, prüft keinen davon. Die Prüfung, die es tut: Lassen Sie den Tor Browser laufen, nehmen Sie den Tunnel herunter und beobachten Sie, ob die Guard-Verbindung auf der physischen Schnittstelle überlebt.
Die Reihenfolge, in der ich prüfe, und beim ersten Fehlschlag anhalte:
ip route get 203.0.113.10gibt das Tunnelgerät zurück.ss -tnp | grep -i torzeigt die Guard-Verbindung mit einer lokalen Tunneladresse.ip -6 routehat keine Standardroute außerhalb des Tunnels, oder IPv6 ist im Client aus.- Den VPN zu trennen, beendet oder leitet die tor-Verbindung um, statt sie auf der physischen Strecke zu lassen.
Welche Reihenfolge zu dem passt, was Sie verteidigen
Beide Reihenfolgen verbergen etwas und legen etwas offen, also ist die Antwort eine Entscheidung über den Beobachter, der Ihnen wichtig ist.
| Observer | Tor over VPN | VPN over Tor |
|---|---|---|
| Your ISP or local network | Sees a VPN connection, not Tor | Sees a Tor guard connection |
| Your VPN provider | Sees Tor use, and your home address | Sees a Tor exit as the client, not your home address |
| Tor entry relay | Sees the VPN exit | Sees your home address |
| Destination website | Sees a Tor exit | Sees a Tor exit |
Lesen Sie es spaltenweise, bis eine Zeile zu dem passt, was Sie verhindern wollen. Wenn die Sorge ein lokales Netzwerk oder ein ISP ist, der Tor aufzeichnet oder blockiert, deckt Tor über VPN das ab. Wenn die Sorge ist, dass der VPN-Betreiber Ihre Heimatadresse erfährt, deckt VPN über Tor das ab und zahlt dafür, indem es die Tor-Nutzung Ihrem eigenen Netzwerk und Ihre Heimatadresse dem Guard offenlegt.
Keine der Anordnungen lässt beide Ränder blind. Einen Beobachter hinzuzufügen, entfernt keinen. Die Notiz des Tor Project zum Betreiben eines VPN mit Tor sagt dasselbe von der anderen Seite: Der Tunnel ändert, wem vertraut wird und welche Fehlerpfade es gibt, also ist er kein Upgrad, das man hinzufügt, ohne zu entscheiden, was man verborgen haben wollte.
Entscheiden Sie zuerst über den Beobachter, wählen Sie zweitens die Reihenfolge und prüfen Sie mit ip route get und ss statt mit der Anzeige des Clients. Wenn der Beobachter jemand ist, der den VPN-Anbieter selbst zwingen kann, behebt keine Reihenfolge das.