Schwebende VPN-Backup-Route übernimmt nicht: Failover-Checkliste

Ihre schwebende VPN-Route ist konfiguriert, die Backup-Distanz ist höher als die der primären, und trotzdem bewegt sich nie etwas. Oder sie bewegt sich und springt Minuten später zurück, während die Funkstrecke noch ausgefallen ist. In beiden Fällen entscheidet etwas anderes als der Fehler, der Sie interessiert, über die Zulässigkeit der Route.

Arbeiten Sie diese Prüfungen der Reihe nach ab. Jede hat eine Abbruchbedingung, und eine fehlgeschlagene Prüfung kann nicht durch die folgenden gerettet werden. Die Beispiele verwenden RouterOS-Syntax, weil Distanz, Gateway-Erreichbarkeit und rekursiver nächster Hop dort in der Konfiguration sichtbar sind, aber die Reihenfolge gilt für jeden Router mit überwachten statischen Routen.

Benennen Sie den Fehler, den das Backup abdecken muss

„Das Primärsystem ist ausgefallen“ sind vier verschiedene Beobachtungen. Ein Funkgerät, das seinen Peer verliert, eine Schnittstelle, die ihren Träger verliert, ein entferntes Gateway, das nicht mehr antwortet, und eine Anwendung, die nicht mehr funktioniert, sehen vom Router aus alle anders aus. Notieren Sie, für welche davon das Design gedacht ist, bevor jemand einen Distanzwert ändert.

Prüfen Sie dann die Unabhängigkeit. Wenn der äußere Transport des VPN über dieselbe Funkstrecke läuft oder über einen Zugangslink, der dasselbe Upstream teilt, ist das Backup keine zweite Fehlerdomäne und wird genau dann ausfallen, wenn Sie es brauchen. Ziehen Sie das primäre Kabel auf dem Papier: Wenn der Transport des Tunnels mitstirbt, deckt die schwebende Route nur Konfigurationsfehler ab, keine Ausfälle.

Hören Sie auf, von der Distanz eine Erkennung zu verlangen

Eine höhere Distanz macht eine Route weniger bevorzugt. Das ist die ganze Aufgabe. Solange die primäre statische Route zulässig bleibt, bleibt die schwebende Route inaktiv, und das ist korrektes Verhalten und kein Fehler. Der Fehler wird erst sichtbar, wenn die primäre zurückgezogen oder als unerreichbar markiert wird.

Für statische Routen erfordert das einen expliziten Tracker:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Lesen Sie, was das prüft: den nächsten Hop, nicht das Ziel. Ein Funkgerät, das auf seiner lokalen Seite noch antwortet, während die Weiterleitung darüber hinaus gestört ist, hält die primäre Route aktiv. Das ist der stille Fall, und Distanz plus Gateway-Prüfung werden ihn nicht erfassen. Wenn dieser Fall wichtig ist, muss die Erkennung von etwas kommen, das die ferne Seite beobachtet: eine Routing-Protokoll-Nachbarschaft oder eine Sonde, deren Pfad und Ergebnisregel Sie selbst festgelegt haben.

Verfolgen Sie, wohin die eigenen Pakete der Sonde gehen

Auch eine Gesundheits-Sonde hat eine Route. Sobald der Datenverkehr auf das VPN wechselt, kann eine unbeschränkte Sonde an dieselbe entfernte Adresse ihm folgen, erfolgreich sein und als Beweis gelesen werden, dass sich das Primärsystem erholt hat. Der Verkehr kehrt auf einen gestörten Pfad zurück, und der Zyklus wiederholt sich.

Binden Sie die Sonde an den Pfad, den sie beurteilen soll. In RouterOS ist der übliche Weg eine Host-Route zum Überwachungsziel über das primäre Gateway, mit einem Bereich, der klein genug ist, dass keine andere Route sie auflösen kann, was das Beispiel für rekursives Failover im RouterOS-Handbuch aufbaut. Bestätigen Sie es in der Live-Tabelle bei aktivem Backup, nicht aus dem Konfigurationskommentar:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Legen Sie fest, was ein Sondenergebnis bedeutet, bevor Sie Ziele hinzufügen

Ein Ziel, das ICMP ablehnt oder in die Wartung geht, sieht genauso aus wie ein Pfadfehler, und drei Ziele ohne Regel liefern Ihnen nur drei Meinungen. Entscheiden Sie zuerst die Regel und setzen Sie sie dann um: Zum Beispiel gilt das Primärsystem als ausgefallen, wenn zwei von drei Zielen über zwei aufeinanderfolgende Intervalle fehlschlagen, niedergeschrieben im Runbook, wo die nächste Person es findet.

Setzen Sie Fehler- und Erholungsschwellen so, dass ein verlorenes Paket den Standort nicht bewegt. Hysterese kostet etwas Erkennungszeit und kauft Stabilität zurück. Wählen Sie das Intervall danach, wie lange ein Ausfall tolerierbar ist, nicht danach, wie schnell die Sonde laufen kann, und halten Sie den Rückfall langsamer als das Failover, damit das Primärsystem sich erst beweisen muss, bevor es den Verkehr zurückbekommt.

Prüfen Sie den Rückweg und die Sitzungsgeschichte

Ein Failover, das nur ausgehend funktioniert, ist ein halbes Design. Der entfernte Standort braucht eine Route zurück zu Ihrem Quellbereich über das VPN, sonst kommt Rückverkehr von einer unerwarteten Adresse und trifft auf Firewall-Zustand, der nicht mehr passt. Bestehende Sitzungen brechen ab, selbst wenn neue Verbindungen funktionieren, also schreiben Sie das in die Abnahmekriterien, statt zu versprechen, dass die Übertragung überlebt.

Halten Sie den Verwaltungszugang vom getesteten Pfad fern. Wenn Ihr einziger Zugang über das Primärsystem läuft, sperrt Sie ein Failover-Test aus dem Gerät aus, das sich falsch verhält.

Führen Sie die Abnahmesequenz aus

Drei Tests decken das meiste ab: physischer Verlust des Primärsystems, ein stiller Weiterleitungsfehler bei noch aktiver Schnittstelle und die Wiederherstellung des Primärsystems. Erfassen Sie für jeden die Quelle und den nächsten Hop der Sonde, die aktive Zielroute und einen frischen erlaubten Anwendungsaustausch in beide Richtungen.

Der stille Fall ist der, der Designs trennt. Wenn das Backup dort nicht übernimmt, haben Sie einen Link-Monitor statt eines Pfad-Monitors gebaut. Entscheiden Sie, ob das akzeptabel ist, und schreiben Sie die Einschränkung dorthin, wo der Bereitschaftsingenieur sie liest. Ein zweiter verbundener Tunnel ist für sich genommen keine fertige Backup-Richtlinie.