Kurzfassung: Ja, es gibt Standard-Lösungen. Nein, du musst nichts Eigenes erfinden. Es ist klassisches WAN-Failover mit Site-to-Site-VPN unter Linux.
Dein Szenario ist sehr typisch: ein Standort mit zwei Internet-Uplinks (primär Glasfaser, sekundär 5G) und ein VServer im RZ mit fixer IP. Ziel ist, dass das VPN beim Ausfall der Glasfaser automatisch über 5G weiterläuft.
Was NICHT passt (wie du korrekt sagst):
-VRRP / CARP: nur Gateway- oder Host-Failover, kein WAN-Failover
-Bonding: setzt gleichartige Links voraus (Latenz, Bandbreite), hier nicht gegeben
Bewährte Standardlösung (empfohlen):
Policy-based Routing + normales Site-to-Site-VPN (WireGuard oder IPsec)
Prinzip:
Der Standort-Server hat zwei Default-Routen:
Glasfaser mit niedriger Metrik
5G mit höherer Metrik
Das VPN hat nur EINEN Peer (der RZ-Server mit statischer IP)
Fällt Glasfaser weg, verschwindet oder wird deaktiviert die Route
Linux nimmt automatisch die 5G-Route
Das VPN baut sich über den neuen Pfad neu auf
Für den RZ-Server ändert sich nichts
Typische Umsetzung:
Debian als Router
Zwei Default-Routen mit unterschiedlichen Metriken
Optional: ip rule / separate Routing-Tables, falls du sauber trennen willst
Health-Check (ping oder tcp-check), der bei Ausfall die Glasfaser-Route entfernt
WireGuard mit PersistentKeepalive = 25 Sekunden
Warum das der Standard ist:
Linux-native Mechanismen
Keine Spezialprotokolle
Robust, gut kontrollierbar
Genau für solche Multi-WAN-Szenarien gedacht
Alternativen (meist unnötig):
Multipath-VPN (MLVPN, OpenMPTCPRouter, komplexe WG-Skripte)
Vorteil: nahtloser Übergang
Nachteil: deutlich mehr Komplexität
Dynamisches Routing (OSPF/BGP)
Technisch korrekt, aber für zwei Hosts Overkill
Klare Antwort:
Ja, es gibt dafür etablierte Lösungen.
Die Standardlösung ist Multi-WAN-Routing auf Linux + normales VPN.
Du musst nichts basteln, nur sauber konfigurieren.
