Default Gateway Failover - ein Interface, ein Subnetz

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
kossmann
Beiträge: 4
Registriert: 19.05.2021 22:22:04

Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von kossmann » 19.05.2021 22:40:19

Hallo zusammen,

ich habe ein Subnetz mit mehreren virtuellen Servern und Clients. Seit vorhin gibt es auch einen zweiten Router als Ersatz für den Fall, dass der DSL-Provider eine Störung hat (so wie heute Abend).

Subnetz: 10.81.0.0/24
Default Gateway: 10.81.0.1 (FritzBox 7590 per VDSL in´s Internet)
Ersatz Gateway: 10.81.0.254 (virtuelles VyOS per WLAN über den Nachbarn in´s Internet)

Nun habe ich das Problem, dass meine Debian-Server nicht mitbekommen, dass die Strecke über das Default Gateway nicht mehr funktioniert. Ich versuche es momentan mit Metriken der Routing-Tabelle (hier am Beispiel eines Servers):

Code: Alles auswählen

iface ens192 inet static
        address 10.81.0.101/24
        #gateway 10.81.0.1
        mtu 1492
        up ip route add default via 10.81.0.1 dev ens192 metric 10
        up ip route add default via 10.81.0.254 dev ens192 metric 50
Grundsätzlich soll die 10.81.0.1 als Gateway genutzt und nur bei Ausfall der Strecke auf 10.81.0.254 ausgewichen werden. Aber dies scheint nicht zu funktionieren (der Router 10.81.0.1 ist weiterhin erreichbar, nicht aber irgendetwas dahinter). Lösche ich die Route über .1, funktioniert´s - aber das soll ja automatisch mit Priorität über .1 laufen.

Hat irgendjemand von euch eine Idee, wie dies zu lösen ist?

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von mat6937 » 20.05.2021 09:56:41

kossmann hat geschrieben: ↑ zum Beitrag ↑
19.05.2021 22:40:19
Lösche ich die Route über .1, funktioniert´s - aber das soll ja automatisch mit Priorität über .1 laufen.
Was genau meinst Du mit "automatisch mit Priorität"?
Nur weil via der 1. default route (mit der besseren metric) z. Zt. nichts erreichbar ist, heißt ja nicht, dass diese Route nicht mehr gültig ist. Policy routing kann man m. W. machen, wenn source und/oder destination verschieden sind. Aber bei deinen beiden default Routen, gibt es keinen Unterschied bei source bzw. bei destination.
Teste mal was passiert, wenn die metric der beiden default routen identisch/gleichwertig ist.

kossmann
Beiträge: 4
Registriert: 19.05.2021 22:22:04

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von kossmann » 20.05.2021 11:50:40

Dein Gedanke ist richtig. Wie soll das System merken, dass die WAN-Strecke hinter Router 1 defekt ist. Nur weil eine beliebige IP im Internet nicht erreichbar ist, heißt das ja noch lange nicht, dass die gesamte WAN-Strecke ausgefallen ist.

Ich würde mir wünschen, dass externe IP-Adressen immer über Router 1 erreicht werden. Wenn dies nicht möglich ist, soll es über Router 2 probiert werden, bis es wieder über Router 1 möglich ist ("automatische Priorität" war wohl nicht so ideal formuliert).

Sobald ich am Default Gateway etwas ändere, wird immer der Weg über das GW der letzten Änderung gewählt, unabhängig von der Metrik - wenn ich meinen Test von letzter Nacht richtig im Kopf habe.

Ich bin aber bestimmt nicht der erste Mensch, der diese Problemstellung hat. Gibt es ggf. einen Router-HealthCheck-Daemon, der die Aufgabe übernimmt (z.B. Ping auf einen Pool von 10 IP-Adressen, von denen mind. 5 erreichbar sein müssen)? Eine weitere Alternative wäre ggf. ein Load-Balancing auf dem neuen virtuellen Router ("Router 2"). Dort 2 Gateways eintragen, Router 1 und WAN-GW... und diese Load-Balancen mit Prio auf Router 1.

mludwig
Beiträge: 793
Registriert: 30.01.2005 19:35:04

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von mludwig » 20.05.2021 12:25:57

pfSense kann multi-Wan mit aktiv/passive oder auch Loadbalancing über 2 WAN-Strecken. Sie prüft per ping, ob der Gateway des jeweiligen Providers erreichbar ist und nutzt dementsprechend die WAN-Strecke - oder eben auch nicht. Insgesamt ist das aber ein doch komplexes Thema mit einigen Fallstricken - die Ausfallsicherheit erkauft man sich im Endeffekt mit zusätzlichen Fehlerquellen und Komplexität.

In deiner jetzigen Konstellation müsste ja jeder Server etc für sich festlegen, welcher Gateway der richtige ist - ob die WAN Strecke oder nur ein Internet Host ausgefallen ist kann ein Client im LAN eigentlich nicht zuverlässig erkennen.

Erstelle z. B. eine VM mit pfSense und richte diese für Multi-WAN ein. Den Monitoring-Host für das erkennen, ob WAN up/down kannst du dann manuell festlegen.

https://docs.netgate.com/pfsense/en/lat ... index.html

kossmann
Beiträge: 4
Registriert: 19.05.2021 22:22:04

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von kossmann » 20.05.2021 12:47:13

Ich musste mich gestern spontan zwischen VyOS und pfSense entscheiden und habe dann auf Grund des des Debian-Unterbaus auf VyOS gesetzt, auch da pfSense den Intel 8260 Wireless Adapter nicht unterstützt. Gucke ich mir aber mal in Ruhe an.

Ja, die "Entscheidung" müsste wohl zentral an einer Stelle getroffen werden. D.h. neben dem physikalischen Router müsste ein virtueller (oder ggf. doch physikalischer Multi-WAN-) Router existieren (momentan VyOS schnell zusammen gefrickelt), der dann als Gateway für alle Clients und Server fungiert - und dort wird die Entscheidung getroffen, ob es über den physikalischen Router mit eigenem WAN-Provider raus geht oder über andere Interfaces (WLAN des Nachbarn, Mobilfunk, ...).

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von unitra » 20.05.2021 15:52:30

Dieser ganze Hokus Pokus mit Mutli-WAn und setzen einer Metrik und prüfen ob irgendwo Im Internet irgendetwas erreichbar ist, und policy based routing und sonst was es da noch gibt, achso VRRP/FHRP/CARP. Das kann man sich alles sparen wenn man das mit OSPF löst und "default originate" einstellt und die Kosten ensprechend setzt. Ist aber ein Failover Szenario. Entweder/Oder. Load-sharing Beide/gleichzeitig nutzten, geht damit nicht mit SoHo Anschlüssen. BTW. Es gibt kein einfaches Load-Sharing mit Heimanwender-Anschlüssen und 1 öffentlichen IP Adresse am Anschluß.

Es ist noch nicht einmal OSPF dafür notwendig. Das würde sogar nur mit RIPv2 funktionieren und nur damit (Failover szenario). Mit nur wenigen Befehlen(default originate wäre hier auch der weg). Der router der die default route vom Provider kriegt announciert dann die default route ins LAN. Wenn keine defualt route geschickt wird vom Provider dann schickt auch der Router OSPF/RIP keine default route. So funktioniert das. Und dann wenn beide Router aktiv sind mit dynamischen Routing. Bei dem Router der der primäre sein soll die Kosten runtersetzten. Und et voila schon habe ich eine failoverfunktion nur mit dynamischem Routing.

kossmann
Beiträge: 4
Registriert: 19.05.2021 22:22:04

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von kossmann » 20.05.2021 16:36:04

Okay, davon habe ich jetzt nur die Hälfte verstanden, aber das ist doch genau das, was ich möchte. Im Normalfall den eigenen VDSL-Provider nutzen und nur im Fall des Ausfalls über das WLAN des Nachbarn (o.ä.). Das mit den "Kosten" hört sich da nach dem richtigen Weg an.

Gibt´s da irgendwo ein HowTo für Dummies? Ansonsten frage ich mal Tante Google und lese mich ein.

Benutzeravatar
bluestar
Beiträge: 2333
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von bluestar » 20.05.2021 17:10:49

kossmann hat geschrieben: ↑ zum Beitrag ↑
20.05.2021 16:36:04
Gibt´s da irgendwo ein HowTo für Dummies? Ansonsten frage ich mal Tante Google und lese mich ein.
Schau dir mal https://lsm.foobar.fi/ an, damit kannst du ein Umschalten des Routings scripten, wenn dein Provider off ist.

wortmann
Beiträge: 1
Registriert: 11.03.2023 17:11:27

Re: Default Gateway Failover - ein Interface, ein Subnetz

Beitrag von wortmann » 11.03.2023 17:24:15

Das Problem beschäftigte mich auch die ganze Nacht, weil ich mal wieder ein Ausfall meines Providers hatte :(
Ich bin diverse Foren und Google Artikel dazu durchgegangen und hab es auch mit pfsence probiert. Leider alles nur Zeit ohne erfolg.

Was hat mir geholfen und klappt jetzt perfekt:

Dieses Script auf meinem Ubuntu Router:

NoPaste-Eintrag41866

Neben dem Script muss das nmap Packet installiert sein für den nping und die ensprechenden yaml für die Netzwerkkonfiguration erstellt werden.

Klappt jedenfalls wunderbar :)

Antworten