Mehrere vpnc-Tunnel mit Prüfungen pro Profil betreiben

Ein vpnc-Profil verbindet sich nach einem Roaming sauber neu; drei von ihnen zerstören abwechselnd gegenseitig ihre Sockets, Routen und Resolver-Zustände. Das mitgelieferte Wiederverbindungsskript ist für einen einzelnen Tunnel geschrieben, deshalb startet es jedes Profil neu, sobald eines davon ausgefallen ist. Das zu beheben erfordert drei Dinge: getrennte lokale Ports, eine Prüfung, die pro Profil einen echten Dienst testet, und eine geordnete Kette, die nie zwei Verbindungen gleichzeitig startet.

Geben Sie jedem Profil einen eigenen lokalen Port

Ein vpnc-Profil, das auf dem standardmäßigen lokalen Port bleibt, konkurriert mit dem bereits laufenden Profil. Die zweite Verbindung schlägt fehl, während die erste den Port hält, und die Logzeile sieht wie ein Gateway-Problem aus, nicht wie ein lokaler Konflikt. Setzen Sie stattdessen eine Zeile pro Profildatei:

Local Port 0

Null lässt den Kernel einen kurzlebigen Port wählen, sodass zwei Profile gleichzeitig aufgebaut werden können. Benennen Sie jede Datei nach dem Gateway und der Gruppe, der sie dient, halten Sie sie nur für root lesbar, und verbinden Sie immer mit dem passenden Profil statt mit einer gemeinsamen Vorgabe. Eine gemeinsame Standarddatei ist der Weg, auf dem ein Skript den falschen Tunnel neu verbindet, nachdem jemand ein Profil umbenannt hat.

Profildateien enthalten Anmeldedaten, deshalb gehören Berechtigungen zum Entwurf und nicht zur Hauswirtschaft. Eine für alle lesbare Datei unter /etc/vpnc gibt das Gruppengeheimnis an jeden lokalen Benutzer weiter. Halten Sie den Modus auf 0600 mit root als Eigentümer und lassen Sie die Skripte die Datei als root lesen, statt Geheimnisse in Argumente zu kopieren. Deshalb sollte ein Prüfskript auch niemals den Dateiinhalt in ein Log schreiben.

Prüfen Sie einen Dienst pro Profil, nicht die Tunneladresse

Eine Echo-Anfrage an die eigene Adresse des Tunnels beweist meist nur, dass die Schnittstelle existiert. Sie sagt nichts darüber aus, ob der dahinterliegende Host die Anwendung noch erreicht, die den Tunnel rechtfertigt. Die Schnittstelle kann oben sein, während die Route dahinter schon weg ist.

Prüfen Sie einen Dienst pro Profil mit einem kurzen TCP-Timeout und verbinden Sie nur das Profil neu, dessen Prüfung fehlgeschlagen ist. Zwei Sekunden trennen einen toten Pfad von einem langsamen, und eine TCP-Prüfung hängt nicht davon ab, dass ICMP irgendwo auf dem Weg erlaubt ist. Ändern Sie zwischen den Profilen nur das Ziel und den Konfigurationsnamen:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

Speichern Sie das als /usr/local/bin/ensure-vpn-ops.sh, machen Sie es ausführbar und wiederholen Sie es für jedes Profil, wobei Sie nur das Prüfziel und den Konfigurationsnamen ändern. Eine Prüfung, die eine Protokollfrage beantwortet, übersteht Gateways, die Echo verwerfen und trotzdem die Dienste weiterleiten, die den Benutzern wichtig sind.

Verketten Sie die Prüfungen, damit sie nie um die Wette laufen

Das mitgelieferte Wiederverbindungsskript kann Ihre Prüfungen nacheinander aufrufen, und die Reihenfolge ist der ganze Punkt. Zwei gleichzeitig laufende vpnc-connect-Aufrufe schreiben die Routing-Tabelle in einer Reihenfolge um, die niemand kontrolliert, und so verliert ein gesundes Profil seine Route.

Halten Sie die Aufrufe im Vordergrund, fügen Sie eine kurze Einschwingverzögerung für die zugrunde liegende Schnittstelle hinzu und planen Sie die Kette aus der cron-Tabelle von root, da nur root die Tunnelrouten umschreiben kann:

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

Halten Sie die Reihenfolge zwischen Startskript und cron-Eintrag identisch, denn eine Kette, die beim Start in anderer Reihenfolge läuft, ist effektiv ein anderes Programm. Wenn ein Profil von den Routen eines anderen abhängt, stellen Sie die Abhängigkeit an die erste Stelle und lassen Sie die spätere Prüfung harmlos fehlschlagen, während der frühere Tunnel noch hochkommt.

Beobachten Sie das Log und brechen Sie dann einen absichtlich

Schreiben Sie eine Zeile pro Lauf mit Profil, Prüfziel, Ergebnis und ergriffener Maßnahme. Ohne das sieht ein Tunnel, der jede Minute flattert, genauso aus wie einer, der nie ausgefallen ist, und ein Fehler in der Prüfung ist von einem Gateway-Ausfall nicht zu unterscheiden. Das Log beweist außerdem, dass die Kette nur das Profil berührt hat, das ausgefallen ist. Schreiben Sie es dorthin, wo es einen Neustart überlebt, sonst verschwinden die Belege mit dem Prozess.

Brechen Sie dann einen Tunnel absichtlich und sehen Sie, was passiert. Stoppen Sie ein einzelnes Profil und prüfen Sie, welche Prozesse und Routen noch vorhanden sind:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

Nur das gestoppte Profil sollte neu verbunden werden, und die anderen Sitzungen sollten sowohl ihre Prozesse als auch ihre Routen behalten. Wenn zwei Profile neu starten, läuft Ihre Kette irgendwo parallel, wo Sie es nicht erwartet haben.

Was der Watchdog nicht tun darf

Ein Watchdog, der alles neu startet, sobald etwas fehlschlägt, sieht im Test gesund aus und verursacht einen Ausfall in einem Wartungsfenster. Starten Sie pro Profil neu, niemals global.

Bevorzugen Sie einen gepflegten Client, wenn das Gateway einen für dasselbe Protokoll anbietet, und schreiben Sie niemals ein Passwort fest in das Skript oder übergeben Sie eines auf einer Kommandozeile, weil die Profildatei das Geheimnis bereits hält. Wenn eine Aufgabe als gewöhnlicher Benutzer laufen muss, sobald der Tunnel steht, senken Sie die Rechte innerhalb des Skripts, statt die ganze Kette unter diesem Konto laufen zu lassen. Lesen Sie schließlich die Routen nach einer Wiederverbindung erneut, weil ein Profil mit einer anderen zugewiesenen Adresse zurückkommen und eine veraltete Route hinterlassen kann, die keine Prüfung an die Tunneladresse je bemerken wird.