So protokollieren und prüfen Sie die genutzte VPN-Ausgangsadresse

Fragen Sie einen Desktop-VPN-Client, welche Server Sie genutzt haben, und die ehrliche Antwort ist meist ein Ortsname. Dieser Name ist der Einstiegspunkt, den Sie gewählt haben, und die Adresse, über die Ihr Datenverkehr das Netz verlassen hat, kann eine ganz andere Maschine sein. In der App ist nichts dafür vorgesehen, die zweite Nummer zu behalten, also muss der Nachweis im Moment der Nutzung entstehen. Es gibt zwei Vorgehensweisen, und nur eine davon übersteht einen Supportfall.

Zwei Aufzeichnungen, von denen nur eine existiert

Die Ansicht des Clients ist bestenfalls eine Liste gewählter Standorte mit Zeitstempeln. Das ist eine Designentscheidung und kein Versehen: Adressen sind Betriebsdetail, sie wechseln zwischen Zuweisungen, und die Offenlegung der Zuordnung macht sowohl Support als auch Missbrauchsbearbeitung schwieriger. Anbieter stellen ihrem Netz Cloud-Instanzen voran, gerade damit der Endpunkt umziehen kann, ohne es jemandem zu sagen. Was die App Ihnen zeigt, ist die Wahl, die Sie getroffen haben, nicht die Route, die sie genommen hat.

Die Aufzeichnung, die Sie selbst anlegen können, ist eine lokale Datei mit einer öffentlichen Adresse und einem UTC-Zeitstempel pro Zeile. Sie ist kleiner, hässlicher und viel nützlicher, weil sie genau das beschreibt, was auch ein Außenstehender sehen kann.

Variante A: Die Ausgangsadresse selbst erfassen

Ein Echo-Dienst gibt die Quelladresse zurück, von der die Anfrage ankam, und das ist per Definition die Ausgangsadresse. Führen Sie die Erfassung aus, nachdem der Tunnel „verbunden“ meldet, denn ein Client, der „verbunden“ sagt, bevor Routen und DNS stehen, protokolliert die Adresse vor dem Tunnel und vergiftet das Log ab der ersten Zeile.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Zwei Details machen diesen Schnipsel brauchbar statt dekorativ. Zeitstempel und Adresse stehen in einer Zeile, sodass ein späteres Parsen keine Datensätze paaren muss, und umask 077 hält die Datei vom Moment ihrer Erstellung an privat. Führen Sie das Skript einmal pro Verbindung aus und nicht einmal pro Start, und halten Sie eine Datei pro Gerät.

Das Log hält fest, wann Sie einen Tunnel genutzt haben und aus welchem Netz Sie erschienen sind – das ist näher an einem Browserverlauf als an einem Zähler. Wählen Sie eine Aufbewahrungsfrist, die Sie verteidigen können, halten Sie die Datei aus gemeinsam genutzten Sync-Ordnern heraus und löschen Sie sie bewusst.

Variante B: Den Anbieter nach einem Verlauf fragen

Manche Anbieter führen Verbindungsprotokolle und beantworten eine Supportfrage mit Zeitstempel und Servernamen. Diese Aufzeichnung beschreibt deren Infrastruktur und nicht Ihren Datenverkehr, und sie ist nur so gut wie ihr Aufbewahrungsfenster und ihre Bereitschaft, nachzusehen. Sie beschreibt außerdem eine Sitzung, keine Anfrage. Das Fenster ist meist kurz, und es wird von der Seite des Anbieters aus gemessen.

Anbieter, die mit Protokollfreiheit werben, können das auf Anfrage nicht liefern, und eine clientseitige Liste der letzten Standorte ist nicht dasselbe. Wer einen Anbieter ohne Protokolle nach einer Ausgangsadresse fragt, bekommt am Ende meist eine Erklärung, warum die Daten nicht existieren.

Was jede Aufzeichnung in einem Supportfall belegen kann

Die beiden Aufzeichnungen beantworten verschiedene Fragen, und in der Tabelle hört der Vergleich auf, akademisch zu sein.

Nur die erste Spalte liegt in Ihrer Hand. Eine Anbieteraufzeichnung kann bestätigen, dass ein Konto zu einem Zeitpunkt verbunden war, doch sie kann nicht bestätigen, welche Anfragen den Tunnel genutzt haben, und sie nennt keine Adresse, die der Anbieter als Betriebsdetail behandelt. Keine der beiden Aufzeichnungen identifiziert eine Person, denn eine geteilte Ausgangsadresse kann in derselben Minute viele Kunden tragen.

Vergleichen Sie beide mit einer Basislinie, bevor Sie einer trauen

Eine Adresse allein beweist nichts. Erfassen Sie die direkte Adresse vor dem Verbinden und die getunnelte danach, und vergleichen Sie sie. Gleiche Werte bedeuten, dass der Tunnel diese Anfrage nicht trägt – sei es wegen eines Split-Tunnels, eines übergeordneten Proxys oder eines Clients, der auf einen direkten Pfad ausgewichen ist.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Wiederholen Sie den Vergleich für DNS und für IPv6, denn ein Adress-Echo belegt den Pfad einer einzigen HTTP-Anfrage und nichts darüber, welcher Resolver geantwortet hat. Ein Gerät, das bei einem der beiden leckt, kann beim anderen völlig gesund aussehen.