Site icon BintoroSoft PDF Tools

VPN Failover: Redundanz für Gateways und Internetleitungen

Red Snapper

Ein zuverlässiges VPN Failover ist für viele Organisationen der Unterschied zwischen „Remote Work läuft“ und „Betrieb steht“. Sobald Mitarbeitende, Filialen, Dienstleister oder Cloud-Workloads über VPN auf zentrale Systeme zugreifen, wird das VPN-Gateway zur kritischen Infrastruktur. Fällt ein Gateway aus oder bricht die Internetleitung weg, sind nicht nur Verbindungen unterbrochen – häufig sind ganze Prozesse blockiert: VoIP, ERP, Support, Wartung, Fileservices oder Administration. Genau deshalb braucht es Redundanz für Gateways und Internetleitungen – und zwar so geplant, dass Failover nicht nur auf dem Papier existiert, sondern in der Praxis schnell, kontrolliert und ohne Nebenwirkungen funktioniert. Dieser Artikel erklärt die gängigen Failover-Modelle (Active/Standby, Active/Active, Multi-Region), zeigt, wie Redundanz bei WAN-Uplinks (Dual ISP, LTE/5G, BGP) umgesetzt wird, und beleuchtet typische Stolperfallen wie asymmetrisches Routing, DNS-Abhängigkeiten, MTU/MSS, Stateful Sessions und fehlende Tests. Ziel ist eine VPN-Architektur, die Ausfälle verkraftet, sauber überwacht wird und sich im Alltag sicher betreiben lässt.

Was bedeutet VPN Failover in der Praxis?

VPN Failover beschreibt die Fähigkeit, bei Ausfall eines Bestandteils (Gateway, Internetleitung, Upstream-Router, Cloud-Region, Identity Provider) schnell auf einen alternativen Pfad umzuschalten, sodass Nutzer und Standorte weiterarbeiten können. Wichtig ist dabei die Unterscheidung zwischen:

In vielen Umgebungen scheitert „Failover“ daran, dass nur das Gateway redundant ist, aber DNS oder SSO als Single Point of Failure bleibt. Redundanz muss daher entlang der gesamten Zugriffskette gedacht werden.

Warum VPN-Gateways und Internetleitungen getrennt redundant sein müssen

Ein häufiges Missverständnis ist: „Wir haben zwei Gateways, also sind wir hochverfügbar.“ Wenn beide Gateways am selben Standort hinter derselben Internetleitung hängen, ist das Risiko nur teilweise reduziert. Ebenso hilft eine zweite Internetleitung wenig, wenn ein einzelnes Gateway ohne HA betrieben wird. Robust wird es erst, wenn zwei Redundanzebenen zusammenkommen:

Grundmodelle für Gateway-Redundanz

Active/Standby (klassisches HA-Cluster)

Bei Active/Standby verarbeitet ein aktiver Knoten den Traffic, der passive Knoten übernimmt bei Ausfall. Vorteile: Einfaches Routing, klare Zuständigkeit, oft leichter zu betreiben. Nachteile: Standby-Ressourcen sind im Normalbetrieb ungenutzt, und Failover kann zu Sessionabbrüchen führen, wenn State nicht synchronisiert wird.

Active/Active (Gateway-Pool)

Bei Active/Active arbeiten mehrere Gateways parallel, oft hinter Load Balancing oder Anycast. Vorteile: bessere Auslastung, horizontale Skalierung, Rolling Updates. Nachteile: höhere Komplexität, Session-Stickiness, mögliche Asymmetrien, anspruchsvollere Fehlersuche.

Multi-Site / Multi-Region (Disaster-Tolerant)

Bei Multi-Site/Region gibt es Gateways in verschiedenen Rechenzentren oder Cloud-Regionen. Das schützt gegen Standortausfälle und ermöglicht Nutzer-nahes Routing (geringere Latenz). Dafür müssen DNS, Routing, Identität und Logging regionsübergreifend geplant werden.

Failover-Mechanismen: Wie Clients und Standorte das „zweite Gateway“ finden

Redundanz funktioniert nur, wenn Clients und Gegenstellen im Fehlerfall automatisch auf den alternativen Endpoint wechseln. Dafür werden typischerweise diese Mechanismen genutzt:

Jeder Mechanismus hat Nebenwirkungen: DNS-Failover hängt von TTL und Client-Caching ab, Anycast kann bei Störungen „springen“, und Load Balancer brauchen Session-Strategien, damit nicht mitten in der Session der Knoten wechselt.

Redundanz für Internetleitungen: Dual ISP, LTE/5G und BGP

Dual ISP (zwei Provider)

Die häufigste und wirksamste Uplink-Redundanz ist ein zweiter Internetprovider mit separatem Zugang. Wichtig ist echte Diversität:

Dual ISP kann aktiv/passiv (Failover) oder aktiv/aktiv (Load Sharing) umgesetzt werden. Für VPN ist aktiv/passiv oft einfacher, aktiv/aktiv erfordert sorgfältiges Routing- und NAT-Design.

LTE/5G-Fallback

Mobilfunk als Backup ist besonders für Filialen attraktiv, weil es schnell, relativ günstig und unabhängig von Festnetztrassen ist. Typische Anforderungen:

BGP für sauberes Multi-Homing

Wenn Sie öffentliche Präfixe und AS betreiben, ist BGP der sauberste Weg für echtes Multi-Homing und kontrolliertes Failover. BGP erlaubt, Pfade zu bevorzugen und im Ausfallfall automatisch umzuschalten. Der Aufwand lohnt sich vor allem bei größeren Umgebungen oder wenn SLA-Anforderungen hoch sind.

Stateful Sessions: Warum Failover oft Sessions trennt

Viele VPN-Verbindungen sind zustandsbehaftet: Security Associations (SAs) bei IPsec, TLS-Sessions bei SSL-VPN, NAT-States am Edge, Session-Stickiness am Load Balancer. Wenn der Knoten wechselt, ist der Zustand oft weg – und die Session muss neu aufgebaut werden. Das ist nicht unbedingt „falsch“, aber es muss eingeplant werden:

Einige HA-Lösungen synchronisieren State zwischen Knoten. Das kann helfen, erhöht aber Komplexität und muss unter Last getestet werden.

Asymmetrisches Routing als Failover-Falle

Failover erzeugt häufig neue Pfade. Wenn Hin- und Rückweg nicht über denselben stateful Kontrollpunkt laufen, droppen Firewalls oder NAT-Geräte Pakete. Typische Ursachen:

Lösung ist fast immer: Symmetrie erzwingen (Routing-Policy, BGP-Prefs, PBR) oder State-Synchronisation sauber betreiben. Asymmetrien sind einer der häufigsten Gründe, warum Failover zwar „umschaltet“, aber danach „nichts geht“.

DNS, SSO und Zertifikate: Abhängigkeiten, die Failover häufig sabotieren

Ein VPN kann redundant sein und trotzdem ausfallen, wenn Abhängigkeiten nicht verfügbar sind:

Best Practice: DNS-Resolver redundant und erreichbar über den Failover-Pfad planen, IdP hochverfügbar betreiben und Zertifikatsinfrastruktur (inkl. CRL/OCSP) in die Verfügbarkeitsplanung aufnehmen.

Site-to-Site Failover: Tunnel, Routing und Health Checks

Bei Site-to-Site-VPNs ist Failover oft eine Kombination aus:

„Tunnel up“ bedeutet nicht automatisch „Service erreichbar“. Deshalb sind Pfad-Checks (z. B. Ping zu internen Zielen, TCP-Checks, BFD) wertvoll, um Blackholing zu vermeiden.

Remote-Access Failover: Nutzererlebnis und Betriebsrealität

Bei Remote Access ist Failover oft stärker nutzergetrieben: Der Client wählt einen Endpoint, baut SSO/MFA auf, bezieht Policies und startet den Tunnel. Für stabiles Failover sind diese Punkte entscheidend:

Monitoring und Tests: Failover ist nur real, wenn es geübt wird

Viele Umgebungen haben „Redundanz“, die nie getestet wurde. Das führt dazu, dass Failover im Ernstfall länger dauert oder Folgefehler auslöst. Ein professioneller Failover-Betrieb umfasst:

Typische Fehler bei VPN Failover und wie Sie sie vermeiden

Praxis-Checkliste: Redundanz für Gateways und Internetleitungen sauber umsetzen

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:

Lieferumfang:

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.

 

Exit mobile version