Kann ein VPN-Betreiber sehen, welche Seiten Sie besuchen?

Fragen Sie, was das VPN sieht, und die Antwort hängt davon ab, wo Sie im Pfad stehen. Auf der Sitzungsebene hat der Betreiber Anmeldeereignisse und Byte-Zählungen. Auf der Paketebene hat er Zieladressen und Zeitverläufe. Auf der DNS-Ebene hat er womöglich die Namen selbst. Jede Ebene beantwortet eine andere Frage, und kein einzelner Schalter verschiebt Sie zwischen ihnen.

Bestimmen Sie die Ebene, bevor Sie etwas behaupten

Dieselbe Verbindung erzeugt an jedem Punkt andere Aufzeichnungen, und eine Aussage über Privatsphäre ist nur sinnvoll, wenn sie den Punkt benennt. Lesen Sie die Tabelle Spalte für Spalte: was auf dieser Ebene existiert, was ein Betreiber dort sehen kann und was dieselben Aufzeichnungen ihm noch immer nicht sagen können.

Eine Ebene als das ganze Bild zu lesen, ist der Anfang sowohl von Übertreibungen als auch von falscher Beruhigung. Ein Anbieter, der sagt, er protokolliere kein Surfen, kann bei der URL-Protokollierung korrekt sein und trotzdem Sitzungsaufzeichnungen behalten, und ein Paketmitschnitt, der nur Adressen zeigt, wird ohne Rückwärtssuchen und Vermutungen nicht zu einer Surfhistorie.

Wenn Sie eine Richtlinie bewerten, suchen Sie den Satz, der jede Ebene beschreibt. Trennt die Richtlinie sie nicht, fragen Sie, welche Aufzeichnungen existieren, statt eine allgemeine Aussage über Verschlüsselung zu akzeptieren.

Sitzungsinventar: was ein Standard-OpenVPN-Server behält

Direkt nach der Installation fängt ein OpenVPN Server keinen Datenverkehr ab. Die normale Ausgabe ist ein Sitzungsinventar: das Konto, das sich angemeldet hat, die Quelladresse, von der es kam, Zeitstempel für Beginn und Ende, die zugewiesene Tunneladresse und die Byte-Summen in jede Richtung. Das ist ein Inventar von Sitzungen, keine Liste von Zielen.

Protokollierungsoptionen können Details ergänzen. Eine höhere Ausführlichkeitsstufe schreibt mehr über den Handshake, und eine Statusdatei kann verbundene Clients auflisten, aber beides macht den Server nicht zu einem transparenten Proxy. URLs entstehen erst durch das Beenden von TLS oder einen ausdrücklichen Proxy, und beides ändert die Vertrauensordnung, statt eine versteckte Funktion freizuschalten.

Deshalb ist die genaue Fassung der Aussage ohne Surfprotokoll enger, als sie klingt. Der Server kennt die Seite nicht, aber er weiß, dass eine Sitzung bestand und ungefähr wie viele Daten sie durchlaufen haben. Ob diese Sitzungsaufzeichnung aufbewahrt wird und wie lange, ist eine separate Richtlinienfrage.

Innere und äußere Pakete sind unterschiedliche Beweise

Ein Paketmitschnitt zeigt, was tatsächlich durch den Tunnel geht. Auf dem Server benennen Sie die Tunnelschnittstelle und schreiben in eine Datei, die offline ausgewertet werden kann:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Diese Datei enthält entschlüsselten inneren Verkehr: die Tunneladresse des Clients als Quelle, Zieladresse und Port, Paketgrößen und Zeitverläufe. Sie enthält den HTTP-Pfad oder den Antwortkörper nicht, sofern TLS nicht irgendwo beendet wurde, und sie ist sensibel: Ihre Aufbewahrung ist eine Richtlinienentscheidung und kein Bequemlichkeitsartikel für die Fehlersuche.

Ein Mitschnitt an der physischen Schnittstelle zeigt etwas anderes. Dort sehen Sie äußere Pakete an den VPN-Endpunkt, mit der verschlüsselten Nutzlast darin. Unbeteiligte Adressen in dieser Datei sind normal, sobald ein virtueller Adapter existiert, weil das Tunnelgerät die inneren Ströme trägt, während der verschlüsselte Transport die äußeren trägt.

Fragen Sie, welche Frage der Mitschnitt beantworten soll. Die Nutzung des Tunnels durch eine Anwendung ist am virtuellen Adapter sichtbar; die Erreichbarkeit des Endpunkts über den Tunnel an der physischen Schnittstelle. Eine der beiden Dateien zu verwenden, als wäre sie das vollständige Bild, führt zu Schlüssen, die die Daten nicht stützen.

DNS ist der Ort, an dem Namen sichtbar werden

DNS bleibt die praktische Ausnahme. Der Resolver sieht die Namen, die er auflösen soll, also erfährt, wer ihn betreibt, welche Seiten ein Client sucht, selbst wenn die späteren Verbindungen verschlüsselt sind. Ein Tunnelmitschnitt zeigt Adressen; der Resolver zeigt Namen.

Prüfen Sie, welche Adresse der Resolver benutzt hat, um einen externen Dienst zu erreichen. Die Antwort ist die Ausgangsadresse des Resolvers, und der Vergleich mit dem VPN-Ausgang sagt Ihnen, ob die Abfrage durch den Tunnel lief:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Stimmt diese Adresse mit der lokalen Verbindung statt mit dem Tunnelausgang überein, hat die Suche das VPN umgangen, und der Name war auf dem lokalen Pfad sichtbar. Wiederholen Sie die Prüfung nach einem Client-Update, weil eine neue Version ändern kann, welchen Resolver das Profil installiert.

Verschlüsseltes DNS verschiebt die Sichtbarkeit, statt sie zu beseitigen. Das Netzwerk sieht die Abfrage nicht mehr, der Resolver aber schon, und die Vertrauensfrage wechselt lediglich die Hände. Der TLS-Servername im Verbindungs-Handshake ist ein weiteres Teilensignal: Er überlebt oft, auch wenn die Nutzlast undurchsichtig ist, sodass Zieladressen nicht die einzigen Metadaten sind, die ein weiterleitender Server beobachten kann.

Drei Arten von Aufzeichnungen und wer sie lesen kann

Sitzungsabrechnung, Aufzeichnungen pro Name und Lecknachweise sind drei verschiedene Produkte mit drei verschiedenen Pflichten. Sitzungsprotokolle sind billig und wenig sensibel, und sie beantworten, wer sich wann verbunden hat. Aufzeichnungen pro Name erfordern einen protokollierenden Resolver oder einen ausdrücklichen Proxy und begründen eine Offenlegungspflicht gegenüber den Betroffenen. Ein Lecknachweis ist ein Test auf Clientseite, der vergleicht, was der Resolver preisgibt, mit dem Tunnelausgang.

Halten Sie fest, welche dieser drei Sie betreiben, wer sie lesen kann und wie lange sie bleibt. Aussagen, ein Dienst führe keine Protokolle, beschreiben eine Ebene und bleiben nur in diesem Rahmen wahr. Derselbe Anbieter kann bei Sitzungen korrekt und bei DNS falsch liegen.

Halten Sie den Test reproduzierbar: dieselbe Resolver-Abfrage, dieselbe Mitschnitt-Schnittstelle und derselbe Vergleich. Eine Datenschutzbehauptung, die sich auf einer benannten Ebene nicht prüfen lässt, ist ein Slogan und kein betrieblicher Fakt.