MikroTik Dual-WAN-Failover für ISPs

Zusammenfassung MikroTik Dual-WAN-Failover hält einen Standort online, indem es den Verkehr automatisch auf einen Backup-Uplink verschiebt, wenn der primäre Link ausfällt. RouterOS bietet drei Bausteine — rekursives Routing mit check-gateway, Netwatch und NAT pro WAN — und die richtige Kombination hängt davon ab, wie schnell und wie smart Ihre Erkennung sein muss. Für ISP-Flotten ist das schwierigere Problem nicht der Konfigurations-Schnipsel, sondern über Hunderte entfernter Standorte hinter CGNAT zu bestätigen, dass das Failover wirklich funktioniert hat. Dieser Leitfaden behandelt beides.

Was Ist MikroTik Dual-WAN-Failover?

MikroTik Dual-WAN-Failover ist eine RouterOS-Konfiguration, die einem Router zwei Internet-Uplinks gibt — einen primären und einen Backup — und den Verkehr automatisch auf den Backup verschiebt, wenn der primäre keine Pakete mehr durchlässt, und ihn nach der Erholung wieder zurückverschiebt. Es ist nicht dasselbe wie Lastverteilung: Failover hält einen Link als Versicherung im Leerlauf, während Lastverteilung den Verkehr über beide streut. Das Ziel ist Kontinuität, nicht zusätzliche Bandbreite, und genau deshalb ist es das Standard-Redundanzmuster für Standorte, die schlicht nicht dunkel werden dürfen.

Der Mechanismus beruht auf der Routenauswahl. RouterOS wählt die aktive Default-Route nach der niedrigsten administrativen Distanz, also geben Sie dem primären eine kleinere Distanz und dem Backup eine größere. Das ganze Design reduziert sich dann auf eine Frage: Wie entscheidet der Router, dass der primäre „unten” ist, und stuft seine Route herab? Treffen Sie diese Entscheidung richtig — schnell genug, aber nicht zappelig — und das Failover ist zuverlässig. Machen Sie es falsch, schalten Sie entweder zu langsam um oder flattern bei jedem verlorenen Paket zwischen den Links.

Schritt 1 — Beide WANs erfassen, bevor Sie eine Route anfassen

Beginnen Sie damit aufzuschreiben, was jeder Uplink tatsächlich ist. Ein fester Glasfaser- oder PPPoE-Primärlink mit statischem oder per PPP zugewiesenem Gateway verhält sich anders als ein Starlink- oder LTE-Backup, das hinter Carrier-Grade NAT sitzt und Ihnen eine dynamische Adresse gibt. Das ist wichtig, weil rekursives Routing nur mit stabilen IP-Gateways funktioniert, nicht mit dynamischen Interface-Typen wie PPPoE oder DHCP, bei denen sich die Adresse ändern kann (MikroTik-Dokumentation — Failover (WAN Backup)). Entscheiden Sie, welcher Link primär, welcher Backup ist und ob einer beim Neuverbinden seine IP wechselt — diese eine Tatsache bestimmt, welche Erkennungsmethode Sie verwenden können.

Schritt 2 — Rekursive Default-Routen mit check-gateway hinzufügen

Der klassische Ansatz nutzt rekursives Routing: Statt die Default-Route direkt auf einen Next Hop zu zeigen, zeigen Sie sie auf ein Probe-Ziel (zum Beispiel einen bekannten öffentlichen Resolver) und fügen eine statische Route hinzu, die RouterOS anweist, dieses Ziel nur über ein bestimmtes WAN-Gateway zu erreichen. Anschließend erstellen Sie zwei Default-Routen, die rekursiv über diese Ziele aufgelöst werden — die primäre mit kleinerer Distanz und aktiviertem check-gateway=ping, die Backup mit größerer Distanz (Scoop — Basic ISP Failover with MikroTik).

Das Verhalten, um das herum geplant werden muss, ist das Timing. Check-gateway deaktiviert eine Route nach zwei aufeinanderfolgenden fehlgeschlagenen Prüfungen, und Prüfungen laufen etwa alle 10 Sekunden, sodass die reale Umschaltung bei rund 20 bis 30 Sekunden landet — und es reagiert nicht auf intermittierenden Paketverlust, nur auf ein vollständig totes Gateway (MikroTik-Dokumentation — Failover (WAN Backup)). Für viele ISP-Kundenstandorte ist das akzeptabel. Für Sprach- oder Zahlungsterminals oft nicht, und genau hier kommt Schritt 4 ins Spiel.

Schritt 3 — NAT für beide Uplinks konfigurieren

Ein Dual-WAN-Router braucht eine separate Masquerade- (oder src-nat-)Regel pro WAN-Interface, damit der jeweils aktive Link den ausgehenden Verkehr korrekt übersetzt; eine einzige an ein Interface gebundene Regel zerstört die Konnektivität in dem Moment stillschweigend, in dem das Failover den Verkehr auf den anderen Link verschiebt. Fügen Sie eine Masquerade-Regel in der srcnat-Chain für das primäre out-interface hinzu und eine zweite für das Backup. Wenn Sie eingehende Dienste veröffentlichen, denken Sie daran, dass dst-nat-Regeln, die an die Adresse des primären gebunden sind, aufhören zu funktionieren, sobald dieser Link — und seine öffentliche IP — verschwindet. Diese Eingangsanfälligkeit ist dieselbe architektonische Falle, die in unserem Fall zu Starlink-IP-Änderungen behandelt wird, und deshalb skaliert ausgangsverankerter Zugriff besser als Port-Forwarding. Zu den NAT-Grundlagen siehe unseren Leitfaden zur NAT-Konfiguration auf MikroTik.

Schritt 4 — Netwatch nutzen, wenn Sie schnellere oder smartere Erkennung brauchen

Wenn 20–30 Sekunden zu langsam sind oder Sie auf degradierte-aber-lebende Links reagieren müssen, ist Netwatch das flexiblere Werkzeug. In RouterOS v7 erhielt Netwatch einen type-Parameter, der mit icmp, tcp-conn, http-get, https-get oder simple proben kann, und Sie können Ihr eigenes Prüfintervall festlegen, statt mit der festen Taktung von check-gateway zu leben (MikroTik-Dokumentation — Failover (WAN Backup)). Jeder Host hat ein up- und ein down-Skript, sodass Sie beim Übergang die primäre Default-Route deaktivieren, einen Alarm auslösen oder das Ereignis protokollieren können.

Viele Betreiber kombinieren beides: Rekursives Routing bewältigt den sauberen Link-Tod, während Netwatch die unordentlicheren Fälle abdeckt und Benachrichtigungen sendet. Ein langlaufender Community-Thread diskutiert genau diesen Kompromiss und ist lesenswert, bevor Sie eine Methode flottenweit standardisieren (MikroTik-Forum — netwatch instead of recursive routing). Was auch immer Sie wählen, halten Sie die Konfiguration an jedem Standort identisch — eine Flotte maßgeschneiderter Failover-Skripte ist selbst ein Ausfall, der nur darauf wartet, einzutreten.

Schritt 5 — Failover an jedem entfernten Standort prüfen

Hier ist der Teil, den die Konfigurations-Tutorials überspringen. Die Routen auf einem Labor-Router hinzuzufügen ist einfach; zu beweisen, dass das Failover auf Hunderten ausgerollter CPEs funktioniert, ist das eigentliche ISP-Problem — und es wird schwerer, wenn der Backup-Link Starlink oder LTE hinter CGNAT ist, weil das Gerät nach dem Umschalten oft keine erreichbare öffentliche IP hat, um es zu verwalten. Wenn Sie das Failover nur bestätigen können, indem Sie auf den Anruf eines Kunden warten, haben Sie eigentlich kein Failover; Sie haben ein Skript, von dem Sie hoffen, dass es läuft.

Hier verändert zentralisiertes Management die Wirtschaftlichkeit. MKController hält jeden Router über einen authentifizierten ausgehenden Tunnel erreichbar, sodass Sie bestätigen können, dass der Backup-Pfad Verkehr trägt, den Failover-Übergang im Monitoring beobachten und eine korrigierte Konfiguration ausspielen können — ohne von einer öffentlichen IP abhängig zu sein, die es auf dem Backup-Link womöglich nicht gibt. Kombinieren Sie das mit Telemetrie: Unsere Leitfäden zum Remote-Monitoring von MikroTik mit Zabbix und zum SNMP-Monitoring für MikroTik zeigen, wie Sie auf das Failover-Ereignis selbst alarmieren, sodass ein stiller Wechsel auf den teuren Backup-Link nie unbemerkt bleibt.

Tipps

• Halten Sie die check-gateway-Probe des Backup-Links auf ein Ziel gerichtet, das Sie über diesen Link erreichen, nicht über den primären, sonst ist Ihr Test bedeutungslos.
• Markieren Sie Failover-Übergänge in Ihrem Monitoring, damit ein Standort, der tagelang auf seinem Backup-Uplink läuft, ein Ticket auslöst — ein Failover, das niemand bemerkt, ist eine wiederkehrende Kostenstelle, kein gerettetes Szenario.
• Testen Sie das echte Kabel, nicht nur die Route: Ziehen Sie den Stecker des primären und stoppen Sie die reale Umschaltzeit.

Bringen Sie das Failover unter eine Steuerebene

Dual-WAN-Failover auf einem einzelnen MikroTik ist ein gelöstes Problem. Es flottenweit zuverlässig zu betreiben — mit konsistenter Konfiguration und der Fähigkeit zu beweisen, dass das Backup auf einem Router funktioniert, den Sie nicht per öffentlicher IP erreichen — ist der Punkt, an dem die meisten Betreiber Geld verlieren. Zentralisiertes, ausgangsverankertes Management schließt diese Lücke.

Starten Sie Ihre kostenlose MKController-Testphase