Drei Arten von OpenVPN-Failover auf pfSense, drei Mechanismen

„OpenVPN-Failover“ auf pfSense umfasst mindestens drei voneinander unabhängige Entwürfe, und jeder davon braucht einen anderen Mechanismus. Einen Tunnel über eine Backup-Internetverbindung am Leben zu halten, sich mit einem anderen Server neu zu verbinden und LAN-Verkehr in einen anderen bestehenden Tunnel zu lenken, sind keine Varianten derselben Funktion. Legen Sie den Fehlerfall fest, gegen den Sie sich absichern, bevor Sie eine Gateway-Gruppe bauen. Eine Gruppe, die einen davon behebt, leistet für die anderen beiden nichts.

Benennen Sie den Fehler, bevor Sie eine Gruppe bauen

Schreiben Sie den Satz auf, der während einer Störung wahr sein soll. „Der Tunnel verbindet sich über das Backup-WAN neu“ und „die Filiale erreicht die Anwendung weiterhin über den anderen Tunnel“ sind verschiedene Sätze. Nur der erste handelt vom Transport.

Dann ordnen Sie ihn einem Mechanismus zu. Ausfall des lokalen WAN ist ein Problem der Schnittstellenauswahl, ein toter Remote-Endpunkt ist ein Problem der Verbindungsliste, und ein unbrauchbarer Pfad innerhalb eines bestehenden Tunnels ist ein Problem von Routing und Policy.

Lokales WAN: den Transport verschieben

Für einen pfSense-OpenVPN-Client wählt die unterstützte Multi-WAN-Anordnung eine passende Gateway-Gruppe als die Schnittstelle, an die der Client bindet. Das ist es, was die äußere Verbindung über die Backup-Strecke verlassen lässt, wenn die primäre ausfällt. Es ändert für sich genommen nicht, wie der innere Verkehr geroutet wird.

Die Serverseite desselben Entwurfs ist getrennt zu betrachten. Ein OpenVPN-Server, der über mehrere öffentliche Adressen erreichbar sein soll, braucht für jeden dieser Einträge einen Listener und eine Eingangs-Policy, nicht nur einen Client, der über zwei Strecken wählen kann. Ein funktionierender öffentlicher Eintrag ist kein Beleg dafür, dass der zweite konfiguriert ist.

Eine Policy-Routing-Regel für weitergeleitete LAN-Pakete ist nicht die Einstellung, die eine lokal erzeugte VPN-Transportverbindung verschiebt. Das sind zwei verschiedene Lookups, und das Ändern des einen ändert das andere nicht.

Remote-Endpunkt: ein anderer Server

Ein alternativer Remote ist eine Funktion der Verbindungsliste. Der Client versucht den nächsten Eintrag, wenn der aktuelle nicht antwortet, was nützlich ist, wenn ein bestimmter Host ausgefallen ist, und nicht, wenn Ihre eigene Uplink-Strecke es ist. Die beiden Fehler sehen vom Schreibtisch eines Nutzers ähnlich aus und brauchen unterschiedliche Korrekturen.

Jeder Kandidat muss ein echter Ersatz sein: kompatible Authentifizierung, kompatible Client-Policy und Zugang zu denselben privaten Ressourcen. Ein zweiter Hostname, der auf dieselbe ausgefallene Infrastruktur auflöst, ist kein Backup. Ein Server ohne die erforderliche Route ist es ebenso wenig, so gesund sein Handshake auch aussehen mag.

Dieser Mechanismus lässt auch nicht zwei Tunnel gleichzeitig weiterleiten. Er ersetzt eine Verbindung nacheinander durch eine andere, und die Lücke dazwischen ist für alles sichtbar, was gerade lief.

Tunnelpfad: einen anderen Ausgang wählen

Wenn zwei Tunnel bereits stehen und der Verkehr den gesünderen nutzen soll, ist der Mechanismus eine zugewiesene VPN-Schnittstelle mit eigenem Gateway plus einer ausdrücklichen Policy-Regel, die den richtigen Verkehr dorthin schickt. Eine Gateway-Gruppe über diese zugewiesenen Schnittstellen kann Priorität und Überwachung ausdrücken.

Dieser Entwurf handelt von Auswahl, nicht von Wiederherstellung. Neue Verbindungen auf den zweiten Tunnel zu verschieben sagt nichts über Sitzungen, die auf dem ersten bereits bestehen, und nichts darüber, ob die Gegenseite die neue Quelladresse akzeptiert. Ihn als Wiederherstellungsmechanismus zu behandeln, setzt die Erwartungen zu hoch.

Wenn die Anforderung ist, dass bestehende Sitzungen überleben, sagen Sie das ausdrücklich. Die meisten Implementierungen migrieren einen laufenden Flow nicht zwischen Tunneln, und ein Entwurf, der so tut, als täten sie es, erzeugt ein Failover, das im Diagramm korrekt aussieht und in der Praxis jede offene Verbindung fallen lässt.

Monitore, NAT und die Fail-Closed-Regel

Ein Monitor sollte etwas prüfen, das der Tunnel liefern soll. Ein Ziel, das vom Tunnel-Peer antwortet, aber nicht aus dem Anwendungsnetz dahinter, meldet gesund, während Nutzer nichts sehen. Ein nicht erreichbares Diagnoseziel meldet tot, während der Pfad in Ordnung ist. Wählen Sie die Adresse bewusst und bestätigen Sie, dass sie nur durch den beabsichtigten Tunnel erreichbar ist.

Prüfen Sie das ausgehende NAT für beide Ausgänge. Eine funktionierende Übersetzung auf dem primären beschreibt nicht die Quelladresse des Backups, und das entfernte private Netz braucht eine Rückroute, die zu der Quelle passt, die Sie präsentieren. Eine Übersetzung, die auf einem Pfad korrekt ist, kann auf dem anderen still falsch sein.

Dann entscheiden Sie, was mit dem Verkehr geschieht, der niemals über das WAN laufen darf. pfSense hat ein definiertes Verhalten für Regeln, deren ausgewähltes Gateway ausgefallen ist, und eine später folgende breite Pass-Regel oder eine Standardroute kann Ihre Absicht zunichtemachen. Schreiben Sie das blockierte Ergebnis als Anforderung auf und prüfen Sie es, indem Sie den Pfad abschalten.

Prüfen Sie Verlust und Wiederherstellung getrennt, mit Verkehr, den Sie erzeugen dürfen, und beobachten Sie drei Dinge gleichzeitig: das WAN, das die äußere Verbindung trägt, den Tunnel, der die Anwendungsanfrage trägt, und den Pfad, den die Antwort nimmt. Ein Paar grüner Gateway-Anzeigen gehört nicht zu diesen drei. Der Netgate-Multi-WAN-Leitfaden beschreibt die Transportbindung und die exportierten Client-Alternativen, auf die sich dies stützt.