Active/Active vs. Active/Passive VPN: Hochverfügbarkeit planen

Red Snapper

1 month ago

Ein belastbares Konzept für Active/Active vs. Active/Passive VPN ist heute ein Kernbaustein jeder modernen Remote-Access- und Standortvernetzung. Sobald VPN-Zugriff geschäftskritisch wird – etwa für Homeoffice, Filialen, Außendienst, IT-Administration oder Cloud-Hybrid-Workloads – ist Hochverfügbarkeit nicht mehr „nice to have“, sondern ein operatives Muss. Gleichzeitig ist „zwei Gateways hinstellen“ keine Hochverfügbarkeit, wenn Failover ungetestet bleibt, DNS/SSO als Single Point of Failure existiert oder asymmetrisches Routing plötzlich Sessions zerreißt. Die Wahl zwischen Active/Passive und Active/Active beeinflusst Kapazität, Komplexität, Failover-Verhalten, Kosten und die alltägliche Betriebsfähigkeit. Active/Passive ist oft einfacher und vorhersehbarer, Active/Active kann besser skalieren und Wartungsfenster vereinfachen – bringt aber zusätzliche Anforderungen an Load Balancing, Session-Stickiness, State-Synchronisation, Routing-Design und Monitoring mit. Dieser Artikel erklärt beide Modelle verständlich, zeigt typische Architekturvarianten, beschreibt Risiken und Best Practices und hilft Ihnen, ein Hochverfügbarkeitsdesign zu planen, das im Ernstfall wirklich funktioniert.

Hochverfügbarkeit beim VPN: Was bedeutet das konkret?

Hochverfügbarkeit (HA) im VPN-Kontext bedeutet: Der VPN-Service bleibt auch dann nutzbar, wenn einzelne Komponenten ausfallen oder gewartet werden. In der Praxis sind mindestens drei Failover-Ebenen relevant:

Gateway-Redundanz: Fällt ein VPN-Knoten aus, übernimmt ein anderer.
Uplink-Redundanz: Fällt ein Internetprovider oder eine Leitung aus, bleibt ein alternativer Pfad verfügbar.
Service-Abhängigkeiten: DNS, SSO/MFA, Zertifikatsdienste (CRL/OCSP), Monitoring und Logging dürfen nicht zum Single Point of Failure werden.

Technisch ist das HA-Modell unabhängig vom VPN-Protokoll (IPsec/IKEv2, TLS/SSL-VPN, WireGuard). Grundlagen zu IPsec sind in RFC 4301 beschrieben, IKEv2 in RFC 7296. Diese Standards erklären u. a., warum VPNs zustandsbehaftete Komponenten (Security Associations, Handshakes) haben, die HA beeinflussen.

Active/Passive VPN: Prinzip, Vorteile und Grenzen

Bei Active/Passive gibt es einen aktiven Knoten, der den gesamten VPN-Verkehr verarbeitet, und einen passiven Knoten, der bereitsteht. Im Fehlerfall übernimmt der passive Knoten. Dieses Modell ist in klassischen Firewall-HA-Clustern sehr verbreitet.

Wie Active/Passive technisch umgesetzt wird

Virtuelle IP (VIP): Beide Knoten teilen sich eine Service-IP; beim Failover „wandert“ die VIP.
State Synchronization (optional): Der aktive Knoten repliziert Session-/State-Informationen an den Standby, damit Sessions weniger häufig abbrechen.
Health Checks: Failover wird ausgelöst, wenn der aktive Knoten oder ein kritischer Pfad (Uplink, Prozess, Auth) als „down“ erkannt wird.

Vorteile von Active/Passive

Einfaches Routing: Ein klarer „Owner“ des VPN-Services reduziert asymmetrische Pfade.
Vorhersehbares Verhalten: Failover ist klar definiert, Debugging oft einfacher.
Gute Wahl für viele KMU: Weniger Komponenten und geringere Betriebs-Komplexität.

Grenzen und typische Risiken

Ressourcen ungenutzt: Standby-Knoten arbeitet im Normalbetrieb nicht produktiv.
Session-Abbrüche: Je nach Lösung brechen Sessions beim Failover ab, wenn State nicht synchronisiert wird.
Failover-Trigger falsch: „Gateway up, aber Internet down“ oder „Tunnel up, aber Auth down“ führt zu Blackholing, wenn Health Checks zu simpel sind.

Active/Active VPN: Prinzip, Vorteile und Grenzen

Bei Active/Active verarbeiten mehrere Gateways gleichzeitig VPN-Verkehr. Das kann über einen Gateway-Pool mit Load Balancer, über Anycast/PoPs oder über clientseitige Auswahlmechanismen erfolgen. Ziel ist, Kapazität zu bündeln, horizontale Skalierung zu ermöglichen und Wartungsfenster durch Rolling Updates zu vereinfachen.

Wie Active/Active technisch umgesetzt wird

Load Balancer: Ein L4/L7-LB verteilt Sessions auf Gateways; Health Checks entfernen defekte Knoten.
DNS-basierte Verteilung: Ein Hostname liefert mehrere A/AAAA-Records (Round Robin) oder wird über Health-Checks umgeschaltet.
Anycast: Mehrere Standorte annoncierten dieselbe IP; Routing führt Nutzer zum „nächsten“ Knoten.
Client-Serverliste: VPN-Clients probieren Gateways in Reihenfolge oder nach Latenz aus.

Vorteile von Active/Active

Skalierbarkeit: Mehr Knoten = mehr Kapazität; Peaks (z. B. morgens) lassen sich besser abfangen.
Bessere Ressourcennutzung: Keine „tote“ Standby-Hardware im Normalbetrieb.
Rolling Maintenance: Updates können nacheinander erfolgen, ohne den Dienst komplett zu unterbrechen.
Regionale Performance: In Multi-Region-Active/Active können Nutzer näher am Einstiegspunkt terminieren.

Grenzen und typische Risiken

Komplexität: Load Balancing, Policy-Konsistenz, Beobachtbarkeit und Fehlersuche sind anspruchsvoller.
Session-Stickiness nötig: Viele VPNs erwarten, dass eine Session beim selben Gateway bleibt.
Asymmetrisches Routing: Hin- und Rückweg können über verschiedene Knoten laufen und stateful Komponenten triggern.
State-Synchronisation schwierig: Nicht jedes Produkt synchronisiert VPN-States zwischen Knoten zuverlässig.

Der Kernunterschied: Kapazität vs. Vorhersehbarkeit

Vereinfacht lässt sich die Entscheidung so lesen:

Active/Passive priorisiert Vorhersehbarkeit und Einfachheit – oft die beste Wahl, wenn Betriebskapazität begrenzt ist.
Active/Active priorisiert Skalierung, Ausnutzung und Wartbarkeit – sinnvoll, wenn viele Nutzer, Peaks oder regionale Anforderungen bestehen.

In großen Umgebungen ist Active/Active häufig „der Standard“, aber nur, wenn Betriebsprozesse, Monitoring und Routingdesign reif genug sind.

Failover-Verhalten: Was passiert mit bestehenden Sessions?

Ein häufig unterschätzter Punkt ist, wie sich Failover auf bestehende Verbindungen auswirkt. VPNs haben Zustände, z. B. IPsec Security Associations oder TLS-Sessions. Bei Failover gibt es drei typische Verhaltensweisen:

Hard Failover: Sessions brechen ab, Clients müssen neu verbinden.
Soft Failover: Sessions bleiben teilweise erhalten (z. B. dank State Sync), aber manche Flows resetten.
Session Continuity: nahezu nahtlos, in der Praxis selten ohne zusätzliche Infrastruktur und strikte Voraussetzungen.

Planen Sie deshalb „User Experience“ mit ein: Für Admin-Zugriffe kann ein kurzer Reconnect akzeptabel sein, für VoIP/Video ist er oft schmerzhaft. QoS und Pfadwahl (Split/Full Tunnel) können die Auswirkungen abmildern, ersetzen aber keine HA-Tests.

Asymmetrisches Routing: Das häufigste Active/Active-Problem

Active/Active erzeugt schnell asymmetrische Pfade, wenn nicht sauber geplant wird. Das ist besonders kritisch bei stateful Firewalls und NAT. Typische Fälle:

Client startet Session über Gateway A, Rückweg wird zu Gateway B geroutet.
Load Balancer verteilt neue Flows anders als bestehende (fehlende Stickiness).
Dual ISP: Hinweg über ISP1, Rückweg über ISP2 – NAT-Translation passt nicht.

Lösungen sind meist: Session-Stickiness, klare Routingpräferenzen (z. B. BGP LocalPref/MED), konsequente Symmetrie am Edge und – wenn verfügbar – State-Synchronisation.

Uplink-Redundanz: Ohne zweite Leitung bleibt HA oft Theorie

Ob Active/Passive oder Active/Active: Wenn alle Gateways am gleichen Internetanschluss hängen, ist ein ISP-Ausfall ein Totalausfall. Uplink-Redundanz ist daher ein Muss, sobald VPN geschäftskritisch ist.

Dual ISP: idealerweise unterschiedliche Provider und unterschiedliche Trassen.
LTE/5G-Fallback: pragmatische Backup-Option für Filialen und kleinere Standorte.
BGP Multi-Homing: saubere Pfadkontrolle, vor allem in großen Umgebungen.

DNS, SSO/MFA und Zertifikate: Abhängigkeiten hochverfügbar machen

HA scheitert häufig nicht am VPN selbst, sondern an Abhängigkeiten:

DNS-Failover: kurze TTL hilft, aber Client-Caches können Umschaltung verzögern; prüfen Sie reale Client-Defaults.
SSO/MFA: wenn der Identity Provider ausfällt, ist Reconnect unmöglich – auch bei perfektem Gateway-Cluster.
CRL/OCSP: Zertifikatsprüfungen müssen im Failover-Pfad erreichbar bleiben.

Best Practice: Resolver und IdP redundant betreiben, Health Checks nicht nur auf „Port offen“, sondern auf den echten Auth-Flow ausrichten.

MTU/MSS und NAT-T: Technische Details, die Failover beeinflussen

Failover kann Pfade ändern – und damit MTU, NAT-Verhalten und Paketverlust. Besonders in Multi-Uplink-Setups (z. B. Festnetz ↔ LTE) ändern sich MTU und Jitter spürbar. Außerdem ist NAT Traversal bei IPsec in vielen Access-Netzen entscheidend (UDP/4500). NAT-T ist in RFC 3947 und RFC 3948 beschrieben.

MSS-Clamping: reduziert Fragmentierungsrisiko bei wechselnden Pfaden.
PMTUD: nicht sabotieren; ICMP-Fehler für MTU müssen funktionieren.
NAT-Timeouts: Keepalives/DPD passend setzen, damit Tunnel nicht „still sterben“.

Entscheidungshilfe: Wann Active/Passive, wann Active/Active?

Eine praxistaugliche Entscheidung orientiert sich an Größe, Kritikalität, Teamreife und Standortstruktur.

Active/Passive passt meist, wenn: Nutzerzahl überschaubar ist, ein Standort dominiert, Betriebsteam klein ist, Debugging einfach bleiben soll, und kurzfristige Reconnects akzeptabel sind.
Active/Active passt meist, wenn: viele Nutzer oder Peaks auftreten, regionale Gateways benötigt werden, Wartungsfenster minimiert werden müssen, horizontale Skalierung gewünscht ist und Observability/Automation vorhanden ist.

Planungs-Blueprint: Hochverfügbarkeit sauber aufsetzen

SLOs definieren: gewünschte Verfügbarkeit, maximale Reconnect-Zeit, akzeptable Sessionabbrüche.
Topologie wählen: Active/Passive (VIP) oder Active/Active (LB/Anycast) – plus Multi-Region, wenn nötig.
Uplinks redundant: Dual ISP, optional LTE/5G; echte Diversität planen.
Routing-Symmetrie sicherstellen: besonders bei Active/Active; NAT- und Firewall-Pfade konsistent.
Abhängigkeiten HA machen: DNS, SSO/MFA, Zertifikatsdienste.
Monitoring: KPIs wie Abbruchrate, Login-Zeit P95/P99, Health Checks, Gateway-CPU, Drops, DPD-Events.
Failover testen: geplant und regelmäßig; nicht nur „Tunnel up“, sondern echte Anwendungen (ERP, RDP, VoIP).

Typische Fehler bei Active/Active und Active/Passive

Failover nur auf Ping: Port offen heißt nicht Auth-Flow ok. Lösung: Health Checks auf realen Login/Traffic.
Keine Session-Stickiness: Active/Active verteilt Flows, Sessions brechen. Lösung: Stickiness oder clientbasierte Bindung.
Asymmetrisches Routing ignoriert: stateful Drops. Lösung: Symmetrie, BGP-Prefs, PBR, State Sync.
DNS/SSO vergessen: Reconnect scheitert. Lösung: HA für Resolver/IdP, niedrige TTLs testen.
Uplink Single Point: ein ISP-Ausfall bleibt Totalausfall. Lösung: Dual ISP oder Mobilfunk-Fallback.

Weiterführende Quellen (Outbound-Links)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.