Redundante IP-Verbindung zwischen zwei Hosts

[Frank K. (fchk)]

Tach.

Folgendes Szenario:
- Server am lokalen Standort
  - angebunden über Glasfaser mit statischen IP-Adressen
  - zweiter Internet-Zugang über 5G-Modem/Router
  - Debian Linux auf eigener Hardware, volle Kontrolle
- VServer in einem RZ irgendwo
  - statische öffentliche IP
  - Virtualisierung via KVM
  - Debian Linux auf fremder Provider-Hardware in einer VM
  - keine eigene Hardware hier möglich

Beide Maschinen sollen über ein VPN miteinander verbunden werden. Wenn 
die Glasfaser-Anbindung ausfällt, soll die 5G-Verbindung übernehmen, bis 
diese wieder bereit ist.

Gibt für dieses Szenario Standard-Lösungen, oder muss ich mir da selber 
etwas basteln?
VRRP oder CARP sind ja nur für Host Failover. Bonding bündelt nur 
gleichartige Verbindungen.

fchk

[M. M. (blackcow)]

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.

[Sebastian R. (sebastian_r569)]

M. M. schrieb:
> Kurzfassung:

Netter KI-Text.

[Frank K. (fchk)]

M. M. schrieb:
> 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

Gut. Wie merkt mein Server denn, dass die Glasfaser weg ist? Das 
Interface ist weiterhin up (hängt an einem Switch), das geht also nicht. 
Bliebe ein Health-Check, der die Durchlässigkeit der Verbindung prüft, 
oder?

fchk

[Christian H. (ch-hunn)]

Verbinde die beiden Netzwerke mittels Tailscale Subnetrouter.

Wenn die Verbindung nur P2P zwischen den beiden Hosts nötig ist, reicht 
Tailscale alleine

[Rene K. (xdraconix)]

Frank K. schrieb:
> Gut. Wie merkt mein Server denn, dass die Glasfaser weg ist? Das
> Interface ist weiterhin up (hängt an einem Switch), das geht also nicht.
> Bliebe ein Health-Check, der die Durchlässigkeit der Verbindung prüft,
> oder?

Richtig, das wird normalerweise über eine externe IP (Monitor IP) 
gelöst. Im Normalfall nimmt man sich da bei einen globalen DNS Server 
ala ipv4: 8.8.8.8 oder eben bei ipv6: ::8888

ÄDTITHT: Im obigen Beispiel (Bild) z.b. habe ich gerade das Telefonkabel 
zur Fritzbox gekappt...