So prüfen Sie, ob ein Linux-VPN-Tunnel wirklich steht

Cron startet alle zehn Minuten ein vollkommen gesundes VPN neu, und derselbe Job lässt ein totes eine Woche lang laufen. Beide Fehler entstehen daraus, „steht“ als einen einzigen Tatbestand zu behandeln, obwohl es mindestens vier sind. Ein Gerät kann administrativ aktiviert, korrekt geroutet, vollständig verschlüsselt sein und trotzdem nichts Nützliches transportieren. Trennen Sie zuerst die Beobachtungen, und die Prüfung schreibt sich fast von selbst.

Link-Flags beschreiben das Gerät, nicht den Pfad

Die Prüfung, die alle kopieren, sucht nach einer Hardwareadresse aus lauter Nullen. Dieser Trick trennt in manchen Treibern eine echte Schnittstelle von einem Platzhalter und beweist im Übrigen nichts, denn ein tun-Gerät hat gar keine MAC-Adresse zu melden. ip -brief link show tun0 liefert stattdessen Flags: UP bedeutet, dass ein Administrator das Gerät aktiviert hat, und LOWER_UP bedeutet, dass der Treiber den Link für nutzbar hält. Zusammen gelesen sagen sie, dass das Gerät existiert und nicht administrativ abgeschaltet ist. Keines von beiden sagt, dass ein Paket irgendwohin gelangen kann.

OpenVPN legt sein tun-Gerät an, bevor Routen installiert werden, sodass die Flags perfekt aussehen können, während nichts geroutet ist. Behandeln Sie sie als Vorbedingung, niemals als Antwort.

Fragen Sie, wohin ein Paket ginge

Die Routenabfrage beantwortet die Frage, die die Flags nicht können. ip route get 10.8.0.1 from 10.8.0.2 nennt die Schnittstelle, die Quelladresse und die Tabelle, die der Kernel verwenden würde – genau das, wogegen ein Split-Tunnel geprüft werden muss. Ohne Quelladresse fragen Sie etwas anderes, und bei Policy-Routing kann die Antwort je nach Quelle abweichen. Das ist der billigste ehrliche Test, weil er dieselben Regeln befragt, die Ihr Verkehr nutzen wird.

Bei WireGuard kommt der Handshake hinzu. wg show gibt pro Peer einen Zeitstempel des letzten Handshakes aus, und ein Zeitstempel, der nicht mehr vorrückt, bedeutet, dass der Peer weg ist, egal was die Schnittstellen-Flags sagen. Eine konfigurierte Schnittstelle ohne aktuellen Handshake ist einer der häufigsten Fehlalarme in selbstgebauter Überwachung.

Tabelle 220 erzählt IPsecs Geschichte

strongSwan installiert Routen für ausgehandelte Selektoren in Tabelle 220, wenn die Routeninstallation aktiviert ist. ip route list table 220 trennt daher ausgehandelt von geroutet: Eine leere Tabelle neben einer geladenen Verbindung bedeutet, dass die IKE- und CHILD-SAs hochkamen, während kein Verkehr in sie hineingelenkt wird. Prüfen Sie ip xfrm state daneben, denn sie listet die installierten Sicherheitsassoziationen und ihre Endpunkte auf.

Eine Trap-Policy ist der Fall, auf den man achten sollte. Sie wartet auf interessanten Verkehr, statt ihn zu routen, sodass die Tabelle leer bleibt, bis etwas den Tunnel auslöst.

Manager-Zustand und Daemon-Zustand sind verschiedene Listen

NetworkManager listet nur die Verbindungen, die ihm gehören. nmcli -t -f NAME,TYPE connection show --active liefert nichts für einen Tunnel, der direkt von wg-quick oder von einem OpenVPN-Daemon gestartet wurde.

Dieser Unterschied zählt, wenn ein Skript entscheiden muss, welchen der beiden Manager es fragt. Nehmen Sie den, der den Tunnel auf diesem Host tatsächlich besitzt, und ignorieren Sie das Schweigen des anderen. Wenn beide existieren, entscheiden Sie, welcher maßgeblich ist, und deaktivieren Sie den zweiten, denn zwei Manager, die auf einer Schnittstelle Routen umschreiben, erzeugen Fehler, die niemand reproduzieren kann. Ein fehlender Eintrag ist eine Information über den Manager, nicht über den Tunnel.

Machen Sie den nächsten Schritt von der Prüfung abhängig, die er braucht

Einen UDP-Port abzufragen beweist nichts über die Bereitschaft, denn UDP kennt keinen Handshake, und nc -u gelingt, sobald das Paket das Gerät verlässt. Prüfen Sie, was der nächste Schritt wirklich verbraucht: eine TCP-Verbindung zum weitergeleiteten Port, eine Anfrage an einen Host innerhalb des Tunnels, einen Namen, der nur dort aufgelöst wird. Begrenzen Sie die Wartezeit mit einem Timeout und einer Versuchszahl und scheitern Sie laut, wenn sie abläuft.

Hooks schlagen Polling, wenn der Client sie anbietet. OpenVPNs --up und --down Skripte laufen, nachdem die Schnittstelle ihren Zustand geändert hat, was das Rennen vollständig beseitigt, doch sie laufen mit den Rechten, die der Daemon behalten hat. Wenn OpenVPN über user und group auf ein unprivilegiertes Konto abgesenkt wurde, läuft der Hook als dieses Konto. Ein Systemdienst neu zu starten verlangt dann sudo, um genau diesen Befehl zu erlauben. Übergeben Sie den Wiederholungsversuch dem Dienstmanager statt einer Cron-Schleife: Eine begrenzte Neustartrichtlinie mit Startlimit macht einen defekten Tunnel sichtbar, während eine unbegrenzte Schleife ihn unbegrenzt verbirgt.