So baust du eine VPN-Failover-Richtlinie auf dem Router ohne Lecks
Lege fest, was der Verkehr tun soll, wenn der bevorzugte Tunnel ausfällt: Backup-Tunnel, normales WAN oder Blockieren. Baue es dann auf dem Router auf und teste es.
Das Failover funktionierte genau wie konfiguriert, und genau das war das Problem. Als der primäre Tunnel ausfiel, verschob der Router die Standardroute auf das Kabelmodem, Laptops surften weiter, und niemand rief an. Zwei Tage später bemerkte jemand, dass die Finanzfreigabe sechs Stunden lang über den offenen Internetpfad erreichbar gewesen war. Eine VPN-Failover-Richtlinie auf dem Router ist kein Routing-Trick; sie ist eine Entscheidung darüber, was der Verkehr tun soll, wenn der bevorzugte Pfad weg ist, und diese Entscheidung muss existieren, bevor der Pfad verschwindet.
Entscheide das Ergebnis, bevor du den Detektor wählst
Meist stehen drei Ergebnisse zur Wahl: betroffene Clients durch einen Backup-Tunnel schicken, sie das normale WAN nutzen lassen oder sie rundweg blockieren. Schreibe auf, welches für welches VLAN, welche SSID oder Geräteklasse gilt. Eine einzige pauschale Regel “auf WAN umschalten” ist der Grund, warum die Finanzfreigabe oben auf einem öffentlichen Pfad landete.
Die drei sind nicht austauschbar. WAN-Fallback hält einen Support-Desk am Telefon, während er interne Namen dem lokalen Resolver preisgibt. Ein Backup-Tunnel bewahrt die Richtlinie, kann aber auf einer Ausgangsadresse landen, die die Gegenseite nicht akzeptiert. Blockieren ist für ein Lohn-VLAN richtig und für ein Gästenetz falsch, das den Tunnel nie genutzt hat.
| Ergebnis | Geeignet für | Was bricht |
|---|---|---|
| Backup-Tunnel | Richtlinie muss gelten, Fernzugriff erforderlich | Neue Ausgangsadresse, Rückroute, langsamere Schlüsselerneuerung |
| Normales WAN | Gäste- oder nur öffentlicher Verkehr | Interne Namen, DNS- und IPv6-Exposition |
| Blockieren | Lohn, Verwaltung, alles nur-VPN | Nutzer verlieren jeden Zugriff und rufen dich an |
Passe den Detektor an den Ausfall an, den du wirklich fürchtest
Handshake-Zustand, Schnittstellenzustand und nutzbare Weiterleitung sind drei verschiedene Signale, und nur das letzte zählt für einen Nutzer. Ein WireGuard-Peer kann einen frischen Handshake zeigen, während das Upstream des Anbieters Pakete ins Leere schickt. OpenVPN Client kann auf “verbunden” stehen bleiben, nachdem die von ihm gesetzte Route nicht mehr aufgelöst wird.
Auf pfSense ist die praktische Anordnung eine Gateway-Gruppe, die von dpinger gespeist wird; dpinger prüft eine Überwachungsadresse und markiert ein Gateway als down, wenn Paketverlust oder Latenz seine Schwellen überschreiten. Richte diese Überwachung auf etwas jenseits des Tunnels, etwa einen Host im fernen LAN oder eine öffentliche Adresse, die du durch ihn erreichst. Sie auf die Peer-Adresse des Tunnels selbst zu richten, misst den Teil, von dem du schon weißt, dass er lebt.
Baue die Gruppe so, dass das Backup die letzte Wahl bleibt
Nutze Stufen statt einer flachen Mitgliederliste. Primär in Stufe 1, Backup-Tunnel in Stufe 2, WAN in Stufe 3 nur für die VLANs, deren Richtlinie es erlaubt. In pfSense liegt das unter System > Routing > Gateway Groups: beide Gateways hinzufügen, ihnen verschiedene Stufen geben, Trigger Level auf member down plus packet loss setzen, speichern und die Gruppe dann als Schnittstellen-Standard oder im Gateway-Feld der Firewall-Regeln anwenden, die sie brauchen.
Für eine OpenVPN-Client-Instanz auf pfSense 2.5 und neuer entscheidet die Default Gateway-Einstellung der Instanz, ob der Tunnel überhaupt die Systemstandardroute ersetzt. Policy-Routing nach Regel verhält sich nur dann wie erwartet, wenn die Route, die du annimmst, tatsächlich installiert ist. Prüfe nach der Änderung Status > Gateways, statt dem Tunnelstatussymbol zu vertrauen.
Zwei Einstellungen verursachen das meiste Flattern. Eine ist ein Prüfintervall, das kürzer ist als die eigene Rekonvergenz des Anbieters. Die andere ist eine Gruppe, in der Primär und Backup eine Stufe teilen, sodass beide jederzeit qualifiziert bleiben. Füge Hysterese über Verlust- und Latenzschwellen hinzu, bevor deine Nutzer die Übergänge für dich spüren.
Schließe die Pfade, die der Tunnel nie besaß
Zuerst DNS-Lecks. Der Resolver antwortet weiter auf dem WAN und leitet dort hinaus weiter, sodass Namen weiter über den ISP aufgelöst werden, während der Verkehr am Tunnel festgenagelt ist. Beschränke die ausgehenden Schnittstellen des Resolvers, schiebe den internen Resolver zu den Clients und blockiere Port 53 für alles andere in den Nur-VPN-VLANs.
IPv6 braucht eine eigene Entscheidung. Ein Dual-Stack-LAN kann den Tunnel verlieren und eine funktionierende globale IPv6-Standardroute behalten, sodass Browser IPv6 bevorzugen und über das WAN hinausgehen, während IPv4 perfekt eingeschlossen aussieht. Entweder route IPv6 in den Tunnel oder höre auf, ein globales Präfix anzukündigen, solange der Tunnel unten ist. Eine halbe Richtlinie ist schlimmer als keine, weil sie zu funktionieren scheint.
Dann der Rückweg. Nutzt der Backup-Ausgang eine andere Quelladresse, muss die Gegenseite wissen, wie sie Verkehr dorthin zurückschickt, und jeder Zustand, der an die alte Adresse gebunden ist, ist bereits tot. Sitzungen, die offen waren, als der Primäre ausfiel, migrieren nicht; sie hängen, bis sie ablaufen, und die Anwendung entscheidet, was sie damit tut.
Teste den Ausfall, das Flattern und den Weg zurück hinein
Zieh den Primären bei harmlosem Verkehr, dann lies vier Dinge: Status > Gateways für die Mitgliedszustände der Gruppe, pfctl -ss für Zustände, die noch am alten Gateway hängen, ein Traceroute von einem Client für den Ausgangspfad und eine Resolver-Abfrage, um zu sehen, welcher Server geantwortet hat.
Jetzt lass es flattern. Bring den Primären dreißig Sekunden hoch, dreißig runter, zweimal. Wenn der Verkehr jedem Übergang folgt, sind die Schwellen zu eng oder die Stufen falsch. Repariere das nach deinem Zeitplan, denn sonst tut es ein Anbieter nach seinem.
Bestätige zuletzt, dass du den Router noch administrieren kannst. Halte einen Out-of-Band-Weg bereit, etwa ein Konsolenkabel, ein Management-VLAN oder ein Mobilfunkmodem. Ein Failover-Test, der dich aussperrt, ist ein Test, den du nicht beenden kannst, und ein unerreichbarer Router kann nicht von selbst zurückfallen.
Bevor du die Richtlinie für fertig erklärst, solltest du vier Fragen ohne Terminal beantworten können: welche VLANs das WAN nutzen dürfen, während der Tunnel unten ist, was der Detektor beobachtet und wie lange er wartet, welche Namensserver und IPv6-Routen mit dem Pfad wandern und wie du wieder hineinkommst, wenn auch das Backup ausfällt. Wenn eine Antwort “was auch immer die Vorgabe war” lautet, gehört die Richtlinie noch dem Router und nicht dir.