VPN-Stabilität testen, ohne Ihr Surfverhalten zu protokollieren

Sie möchten wissen, ob der Tunnel den Schlaf eines Laptops übersteht, einen Wechsel zwischen Zugangspunkten, oder eine Stunde voller Anrufe, und möchten dabei niemandem ein Protokoll von allem geben, was Sie lesen. Drei Dinge beantworten das: eine feste Sonde, dieselben vier Fakten nach einem Zeitplan abgetastet und das Ereignis, das sie verändert hat, schriftlich festgehalten. Zehn Minuten davon schlagen einen Nachmittag, in dem Sie zusehen, wie eine Seite nicht lädt. Das Protokoll, das am Ende übrig bleibt, ist außerdem kurz genug, um es einem Ticket anzuhängen, ohne die Hälfte zu schwärzen.

Legen Sie fest, was stabil bedeuten muss

„Das VPN ist abgefallen“ sind vier verschiedene Fehler in einem Wort. Der Peer kann seinen Handshake verlieren, die Route kann auf das lokale Gateway zurückfallen, die Namensauflösung kann zu einem Server gehen, der durch den Tunnel nie antwortet, oder all das kann gesund sein, während eine Anwendung weiterhin scheitert. Entscheiden Sie vor dem Sammeln, welcher Fall zu Ihrem Symptom passt, denn jeder braucht eine andere Sonde. Wählen Sie dann ein Intervall, das Sie durchhalten: eine Probe alle dreißig Sekunden über zehn Minuten erfasst einen Roaming-Wechsel, ohne den Test zur Arbeitslast zu machen.

Wenn die Beschwerde ein einfrierender Anruf ist, während Sie in die Küche gehen, ist die Eigenschaft, die Sie brauchen, ob eine frische Anfrage nach dem Roaming abgeschlossen wird. Das lässt sich in einer Zeile prüfen und zeichnet überhaupt kein Surfverhalten auf.

Legen Sie eine harmlose Sonde fest

Wählen Sie ein Ziel, das Sie abfragen dürfen und das nicht an Ihre Konten gebunden ist: einen Dokumentationshost, einen internen Status-Endpunkt oder das Gateway des Tunnels selbst. Machen Sie den Vorgang wiederholbar, zum Beispiel curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, der eine Zeile pro Versuch ausgibt. Halten Sie dieses Ausgabeformat für den gesamten Lauf fest. Ein Statuscode und eine Dauer, zweimal auf dieselbe Weise erhoben, sind das, was zwei Läufe vergleichbar macht.

Widerstehen Sie der Seite, auf die Sie sich tatsächlich verlassen. Eine Bank- oder Webmail-Seite zieht Tracker, Weiterleitungen und persönliche Inhalte in die Messung und schreibt Sitzungskennungen in alles, was Sie später in ein Ticket einfügen. Verwenden Sie für die ganze Untersuchung dasselbe Ziel und notieren Sie es neben dem Intervall.

Tasten Sie die vier Fakten ab

Peer-Zustand, Route, Resolver und eine frische Anfrage sind die vier Beobachtungen, und jede hat eine billige Quelle. Bei WireGuard liefert wg show wg0 latest-handshakes den Zeitstempel des Peers, und ip route get 1.1.1.1 zeigt, welche Schnittstelle der Kernel verwenden würde. Bei OpenVPN steht derselbe Zustand in der Statusdatei, die --status /run/openvpn/status 10 schreibt, oder hinter state auf der Verwaltungsschnittstelle. Ein Windows-Client bleibt in PowerShell mit Get-NetAdapter und Resolve-DnsName.

Schleifen Sie sie in einem Terminal, damit jede Zeile einen Zeitstempel trägt: for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. Diese Schleife deckt drei der sechs Protokollfelder ab; die Client-Version wird einmal oben eingetragen, und der Zeitstempel des Ereignisses kommt hinzu, wenn das Ereignis eintritt.

Der Resolver ist der Fakt, den Leute auslassen, und dig +short versteckt ihn, weil diese Form nur die Antwort ausgibt. Fragen Sie den Server ausdrücklich mit dig example.com | grep SERVER: ab, oder nutzen Sie nslookup example.com, wo dig nicht installiert ist, was die Adresse des Servers ausgibt, an den die Abfrage ging. Ein alter Handshake auf einem untätigen Tunnel ist auch nicht automatisch ein Fehler, da WireGuard nur dann neue Schlüssel aushandelt, wenn Verkehr zu schützen ist.

Lösen Sie das Ereignis aus, kein Leck

Nehmen Sie fünf ruhige Minuten als Grundlinie vor dem Ereignis, das Sie interessiert, sei es das Schließen des Deckels, ein Weg zu einem anderen Zugangspunkt oder der Wechsel zu einem Handy-Hotspot. Notieren Sie die Zeit, zu der Sie es ausgelöst haben, damit die Proben auf beiden Seiten ausgerichtet werden können.

Ohne diesen Zeitstempel zeigt das Protokoll eine Lücke, und niemand kann sagen, ob der Client oder das Netzwerk sie geschlossen hat. Zwei Läufe mit dem Ereignis an verschiedenen Stellen sind mehr wert als zehn ohne eines. Nutzen Sie die eigenen Trenn- und Wiederverbindungssteuerungen des Clients. Schalten Sie nicht den Kill-Switch ab und schieben Sie keinen Verkehr am Tunnel vorbei, um zu sehen, was passiert, denn auf einem verwalteten Laptop ist das ein Richtlinienverstoß und auf Ihrem eigenen Rechner erzeugt es genau die Exposition, für die Sie getestet haben.

Halten Sie ein Protokoll klein genug, um es zu beenden

Sechs Felder pro Probe: Zeit, Client-Version, Endpunkt, Zugangsnetz, Ereignis, Ergebnis. Lassen Sie URLs, Nutzlasten, Token und alles weg, was eine Sitzungskennung trägt, denn das Protokoll ist Beweis über den Tunnel und nichts anderes. Legen Sie es neben die Schleife, damit die nächste Person sie erneut ausführen kann, ohne zu fragen, was die Spalten bedeuten.

Wiederholen Sie den Test nach einer Änderung mit derselben Sonde und demselben Intervall; tauschen Sie Ziel und Client-Version gemeinsam, gehört das Ergebnis zu keinem von beiden. Ein sauberer Lauf über zehn Minuten ist Beleg für diese Bedingungen und dieses Ziel, kein Versprechen über das Hotelnetz des nächsten Monats. Bewahren Sie Skript und Protokollvorlage dort auf, wo Sie sie finden. Die dokumentierten Einschränkungen von WireGuard lohnen eine Lektüre, bevor Sie einen Abbruch dem Protokoll zuschreiben.