Firewall-Hochverfügbarkeit: Den Failover testen, den Sie annehmen

Firewall-Hochverfügbarkeit scheitert häufiger daran, dass sie offen bleibt, als daran, dass sie umschaltet. Ein HA-Paar, das nie unter echter Last getestet wurde, ist eine Annahme, keine Maßnahme. Der Failover, dem Sie vertrauen, ist meist der, den Sie nur in einem ruhigen Wartungsfenster ohne Verkehr gelingen sahen. Über Hunderte Firewall-Migrationen hinweg ist die häufigste Resilienzlücke ein gesund aussehendes HA-Paar, das noch nie unter Produktionslast und mit echtem Sitzungszustand zum Umschalten gezwungen wurde.

Dieser Leitfaden behandelt, warum HA-Paare still die Fähigkeit zum Umschalten verlieren, den Failover-Test, der Resilienz wirklich beweist, den realen Kompromiss zwischen Active/Passive und Active/Active und die Änderungsdisziplin, die ein Paar tatsächlich redundant hält statt nur auf dem Papier.

Warum HA-Paare aufhören, hochverfügbar zu sein

Ein HA-Paar verschlechtert sich leise. Beide Einheiten bleiben grün, das Dashboard meldet synchron, und doch würde ein echter Failover Verkehr verlieren. Der Fehler ist fast nie die Hardware. Es sind Drift und ungeprüfte Annahmen, die sich über Monate von Änderungen zwischen den beiden Einheiten ansammeln.

Fünf Ursachen erklären die meisten stillen HA-Ausfälle. Konfigurationsdrift zwischen aktiver und Standby-Einheit, wenn eine Änderung nur auf einer angewandt wurde. Lücken in der Sitzungstabellen-Synchronisation, wenn die Standby-Einheit den Zustand für bestehende Verbindungen nie erhielt. Asymmetrisches Routing, das die Standby-Einheit nicht reproduzieren kann. Nicht übereinstimmende Lizenzen, Software-Stände oder SFP-Module, die erst im Moment des Umschaltens zählen. Und Preempt-Einstellungen, die niemand validiert hat, sodass das Paar flattert oder nicht zurückgibt. Jede ist unsichtbar bis zum Failover, also genau dann, wenn Sie es sich nicht leisten können, sie zu entdecken.

Der Failover-Test, der Resilienz wirklich beweist

Ein echter Failover-Test nimmt die aktive Einheit unter produktionsnaher Last außer Betrieb und misst, ob Sitzungen überleben, nicht nur, ob die Standby-Einheit aktiv wird. Ein Ping im Wartungsfenster beweist fast nichts. Der Test, der zählt, hat vier Eigenschaften: Er läuft unter repräsentativem Verkehr, er wird Ende-zu-Ende beobachtet, er misst das Überleben von Sitzungen, und er bestätigt sauberes Zurückschalten.

• Unter Last. Planen Sie ihn, aber leeren Sie den Verkehr nicht vorher. Es geht darum zu sehen, was echte Verbindungen tun, wenn die aktive Einheit verschwindet. Langlebige Sitzungen (Datenbank, VoIP, Dateiübertragung) zeigen die Sync-Lücken.
• Ende-zu-Ende beobachtet. Beobachten Sie von der Anwendungsseite, nicht von der Firewall-Konsole. Die Firewall meldet einen sauberen Failover, selbst wenn die Anwendung einen 30-Sekunden-Ausfall sah.
• Sitzungsüberleben, nicht nur Rollenwechsel. Messen Sie, wie viele bestehende Verbindungen mitgenommen wurden. Eine Standby-Einheit, die aktiv wird, aber jede Sitzung zurücksetzt, hat den Test nicht bestanden, obwohl sie Erfolg meldet.
• Sauberes Zurückschalten. Erzwingen Sie die Rückkehr der ursprünglichen Einheit und bestätigen Sie, dass das Paar ohne zweiten Ausfall in einen bekannten Zustand zurückkehrt. Ungetestetes Failback ist ein eigener Vorfall.

Active/Passive vs Active/Active

Der gewählte HA-Modus verändert, was Sie testen und wem Sie ausgesetzt sind. Active/Passive ist einfacher und für die meisten Umgebungen die richtige Voreinstellung. Active/Active verdoppelt Durchsatz und Komplexität und verbirgt Fehler durch asymmetrische Pfade, bis die Last die Kapazität einer Einheit übersteigt.

Die Active/Active-Falle ist die Kapazitätsplanung. Zwei Einheiten, die je bei 60 Prozent laufen, sehen gesund aus, bis eine ausfällt und die überlebende 120 Prozent tragen soll. Das kann sie nicht, also wird der Failover zum Brownout. Active/Active ist nur ehrlich, wenn jede Einheit die gesamte Last allein tragen kann.

Änderungsmanagement hält ein Paar redundant

Redundanz ist kein einmaliger Entwurf, sondern eine Eigenschaft, die Sie bei jeder Änderung pflegen. Der schnellste Weg, ein HA-Paar zu zerstören, ist, eine Regeländerung, ein Software-Update oder eine Zertifikatsrotation nur auf der aktiven Einheit anzuwenden und die Standby zu vergessen, oder auf beiden anzuwenden, aber nie zu prüfen, dass sie konvergiert sind. Konfigurationsdrift zwischen HA-Partnern ist eine konkrete, wiederkehrende Klasse nicht autorisierter Abweichung, die ein gesunder Änderungsprozess erkennt und ein ad-hoc-Prozess nicht.

Jede Firewall-Änderung an einem HA-Paar hat drei Schritte, nicht einen: anwenden, replizieren und im Sync prüfen. Die Prüfung ist der Schritt, den Teams überspringen. Dieselbe Drift-Erkennung, die nicht autorisierte Einzelgerät-Änderungen erkennt und im Leitfaden zur Policy-Drift-Erkennung beschrieben ist, gilt zwischen den beiden Mitgliedern eines Paares. Notfalländerungen sind der riskanteste Moment: unter Druck wird die Standby zuerst vergessen, weshalb der Notfall-Änderungsprozess eine Sync-Prüfung nach dem Vorfall enthalten muss. Der weitere Rhythmus steckt im Firewall-Änderungsmanagement-Prozess.

Compliance-Erwartungen

Resilienz und Kontinuität sind in den Rahmenwerken, die wesentliche und Finanzunternehmen regeln, ausdrückliche Pflichten. Der erwartete Nachweis ist ein dokumentierter HA-Entwurf plus ein Protokoll eines echten, aktuellen Failover-Tests, kein Hersteller-Datenblatt mit Fünf-Neunen-Versprechen.

Für Finanzunternehmen ist das Failover-Testprotokoll Teil der DORA-Resilienztest-Nachweise im DORA-Firewall-Compliance-Leitfaden, und für NIS2-wesentliche Einrichtungen steht es neben der Dokumentation im NIS2-Artikel-21-Nachweismapping.

Wiederkehrende Fehlermuster

Vier HA-Fehlermuster treten in geprüften Migrationen immer wieder auf, und alle vier werden von einem echten Test erkannt, bevor sie zum Ausfall werden.

Die nie getestete Standby. Das Paar wurde bei der Installation korrekt gebaut und seitdem nie umgeschaltet. Jahre an Drift liegen unvalidiert. Der erste echte Failover ist zugleich der erste Test, in Produktion, während eines Vorfalls.

Das Split-Brain-Paar. Ein Ausfall der Heartbeat-Verbindung lässt beide Einheiten glauben, sie seien aktiv. Dedizierte, redundante Heartbeat-Pfade und getestete Preempt-Logik verhindern es. Eine gemeinsame Daten-und-Heartbeat-Leitung ist die übliche Ursache.

Das überbuchte Active/Active. Beide Einheiten laufen bequem, bis eine ausfällt und die überlebende die kombinierte Last nicht tragen kann. Die Kapazität muss für den Einzelbetrieb bemessen sein, nicht für den Normalzustand.

Die Asymmetrie-Überraschung. Verkehr tritt über eine Einheit ein und versucht, über die andere auszutreten, und die zustandsbehaftete Prüfung verwirft ihn. Häufig nach einer Routing-Änderung, die nie gegen ein Failover-Szenario getestet wurde. Das überschneidet sich mit den Konsistenzproblemen gemischter Plattformen im Leitfaden zur Multi-Vendor-Firewall-Verwaltung.

Häufige Fragen

Wie oft sollte ein Firewall-Failover getestet werden?

Mindestens jährlich und nach jeder wesentlichen Änderung am Paar: einem Software-Upgrade, einer Routing-Änderung oder einem Hardwaretausch. Hochkritische Umgebungen testen halbjährlich. Wichtiger als der Kalender ist die Änderung: Ein seit dem letzten Test verändertes Paar ist faktisch ungetestet.

Garantiert Sitzungssynchronisation einen Failover ohne Ausfall?

Nein. Sync verbessert das Überleben, garantiert es aber nicht. UDP-Flüsse, bestimmte Zustände der Anwendungsschicht und sehr neue Verbindungen sind im Moment des Failovers womöglich nicht in der synchronisierten Tabelle. Ihre echte Überlebensrate kennen Sie nur, wenn Sie sie unter Last messen.

Ist Active/Active immer schneller als Active/Passive?

Nur bis etwas ausfällt. Active/Active liefert im Normalzustand mehr Durchsatz, doch wenn nicht jede Einheit die volle Last allein tragen kann, wird der Geschwindigkeitsvorteil bei einem Ausfall zum Brownout. Für die meisten Umgebungen ist Active/Passive mit einer korrekt bemessenen Einzeleinheit der ehrlichere Entwurf.

Was ist Split-Brain und wie verhindere ich es?

Split-Brain ist, wenn beide HA-Mitglieder sich für aktiv halten, meist nach einem Ausfall der Heartbeat-Verbindung, was doppelte IPs und Störungen verursacht. Verhindern Sie es mit dedizierten, redundanten Heartbeat-Leitungen getrennt vom Datenpfad sowie validierten Preempt- und Quorum-Einstellungen.

Ersetzt HA Backups und Konfigurationsversionierung?

Nein. HA schützt vor Hardware- und Leitungsausfall. Es schützt nicht vor einer fehlerhaften Änderung, die sich sofort auf beide Einheiten repliziert. Sie brauchen weiterhin Konfigurationsversionierung und die Fähigkeit zum Rollback, so wie ein gesunder Änderungsprozess jede Regeländerung behandelt.

Weiterführende Quellen

Maßgebliche externe Quellen:

• NIST SP 800-34 Rev 1, Contingency Planning Guide
• ISO 22301, Business Continuity Management
• BSI IT-Grundschutz (Verfügbarkeit und Notfallmanagement)