MikroTik dual-WAN failover pro ISP

Shrnutí MikroTik dual-WAN failover udržuje lokalitu online tím, že automaticky přesune provoz na záložní uplink, když primární spoj selže. RouterOS vám dává tři stavební bloky — rekurzivní routování s check-gateway, Netwatch a NAT na WAN — a správná kombinace závisí na tom, jak rychlá a jak chytrá musí vaše detekce být. Pro flotily ISP není těžším problémem konfigurační útržek, ale potvrzení napříč stovkami vzdálených lokalit za CGNAT, že failover skutečně zafungoval. Tento průvodce pokrývá obojí.

Co Je MikroTik dual-WAN failover?

MikroTik dual-WAN failover je konfigurace RouterOS, která dává routeru dva internetové uplinky — primární a záložní — a automaticky přesouvá provoz na záložní, když primární přestane propouštět pakety, a poté jej přesune zpět, jakmile se obnoví. Není to totéž co vyvažování zátěže: failover drží jeden spoj v nečinnosti jako pojistku, zatímco vyvažování zátěže rozkládá provoz mezi oba. Cílem je kontinuita, ne dodatečná šířka pásma, a právě proto je to výchozí vzor redundance pro lokality, které jednoduše nesmějí zhasnout.

Mechanismus spočívá na výběru trasy. RouterOS volí aktivní výchozí trasu podle nejnižší administrativní vzdálenosti, takže primárnímu dáte menší vzdálenost a zálohu větší. Celý návrh se pak redukuje na jednu otázku: jak router rozhodne, že primární je „dole”, a degraduje jeho trasu? Udělejte toto rozhodnutí správně — dostatečně rychle, ale ne přecitlivěle — a failover je spolehlivý. Udělejte to špatně a buď přepínáte příliš pomalu, nebo poblikáváte mezi spoji při každém ztraceném paketu.

Krok 1 — Zmapujte obě WAN, než se dotknete trasy

Začněte tím, že si zapíšete, čím každý uplink skutečně je. Pevný optický nebo PPPoE primární spoj se statickou nebo přes PPP přidělenou bránou se chová jinak než Starlink nebo LTE záloha, která sedí za Carrier-Grade NAT a předává vám dynamickou adresu. Na tom záleží, protože rekurzivní routování funguje pouze se stabilními IP branami, ne s dynamickými typy rozhraní jako PPPoE nebo DHCP, kde se adresa může změnit (Dokumentace MikroTik — Failover (WAN Backup)). Rozhodněte, který spoj je primární, který záložní a zda některý při opětovném připojení mění svou IP — tento jediný fakt určuje, kterou metodu detekce můžete použít.

Krok 2 — Přidejte rekurzivní výchozí trasy s check-gateway

Klasický přístup používá rekurzivní routování: místo aby výchozí trasa směřovala přímo na next hop, nasměrujete ji na cíl sondy (například známý veřejný resolver) a přidáte statickou trasu, která RouterOS říká, aby tento cíl dosahoval pouze přes konkrétní WAN bránu. Poté vytvoříte dvě výchozí trasy řešené rekurzivně přes tyto cíle — primární s menší vzdáleností a zapnutým check-gateway=ping, zálohu s větší vzdáleností (Scoop — Basic ISP Failover with MikroTik).

Chování, kolem kterého je třeba plánovat, je časování. Check-gateway deaktivuje trasu po dvou po sobě jdoucích neúspěšných kontrolách a kontroly běží zhruba každých 10 sekund, takže reálné přepnutí dopadne kolem 20 až 30 sekund — a nereaguje na občasnou ztrátu paketů, jen na zcela mrtvou bránu (Dokumentace MikroTik — Failover (WAN Backup)). Pro mnoho zákaznických lokalit ISP je to přijatelné. Pro hlasové nebo platební terminály často ne, a právě tam přichází ke slovu Krok 4.

Krok 3 — Nakonfigurujte NAT pro oba uplinky

Dual-WAN router potřebuje zvláštní pravidlo masquerade (nebo src-nat) na každé WAN rozhraní, aby kterýkoli spoj, který je aktivní, správně překládal odchozí provoz; jediné pravidlo vázané na jedno rozhraní tiše rozbije konektivitu v okamžiku, kdy failover přesune provoz na druhý spoj. Přidejte jedno pravidlo masquerade v řetězci srcnat pro primární out-interface a druhé pro zálohu. Pokud publikujete jakékoli příchozí služby, pamatujte, že pravidla dst-nat vázaná na adresu primárního přestanou fungovat, jakmile tento spoj — a jeho veřejná IP — zmizí. Tato příchozí křehkost je stejná architektonická past popsaná v našem případě změn IP u Starlinku, a proto se přístup ukotvený na odchozí straně škáluje lépe než přesměrování portů. Pro základy NAT viz našeho průvodce konfigurací NAT na MikroTik.

Krok 4 — Použijte Netwatch, když potřebujete rychlejší nebo chytřejší detekci

Když je 20–30 sekund příliš pomalých nebo musíte reagovat na degradované-ale-živé spoje, je Netwatch flexibilnějším nástrojem. V RouterOS v7 získal Netwatch parametr type, který umí sondovat pomocí icmp, tcp-conn, http-get, https-get nebo simple, a můžete si nastavit vlastní interval kontroly místo života s pevnou kadencí check-gateway (Dokumentace MikroTik — Failover (WAN Backup)). Každý host má skript up a down, takže při přechodu můžete deaktivovat primární výchozí trasu, vyvolat upozornění nebo událost zaznamenat.

Mnoho operátorů obojí kombinuje: rekurzivní routování zvládá čistou smrt spoje, zatímco Netwatch pokrývá ty chaotičtější případy a posílá oznámení. Dlouho běžící komunitní vlákno přesně tento kompromis rozebírá a stojí za přečtení, než jednu metodu standardizujete napříč flotilou (Fórum MikroTik — netwatch instead of recursive routing). Ať zvolíte cokoli, držte konfiguraci na každé lokalitě identickou — flotila na míru psaných failover skriptů je sama o sobě výpadek, který jen čeká, až nastane.

Krok 5 — Ověřte failover na každé vzdálené lokalitě

Tady je část, kterou konfigurační návody vynechávají. Přidat trasy na jednom dílenském routeru je snadné; dokázat, že failover funguje na stovkách nasazených CPE, je skutečný problém ISP — a je těžší, když je záložní spoj Starlink nebo LTE za CGNAT, protože zařízení po přepnutí často nemá dostupnou veřejnou IP, přes kterou by se dalo spravovat. Pokud můžete failover potvrdit jen tím, že počkáte, až zavolá zákazník, ve skutečnosti failover nemáte; máte skript, o němž doufáte, že běží.

Tady centralizovaná správa mění ekonomiku. MKController udržuje každý router dostupný přes ověřený odchozí tunel, takže můžete potvrdit, že záložní cesta nese provoz, sledovat přechod failoveru v monitoringu a vysunout opravenou konfiguraci — bez závislosti na veřejné IP, která na záložním spoji nemusí existovat. Spojte to s telemetrií: naši průvodci vzdáleným monitorováním MikroTik se Zabbix a SNMP monitorováním pro MikroTik ukazují, jak upozorňovat na samotnou událost failoveru, aby tiché přepnutí na drahý záložní spoj nikdy nezůstalo bez povšimnutí.

Tipy

• Držte sondu check-gateway záložního spoje namířenou na cíl, který dosahujete přes tento spoj, ne přes primární, jinak je váš test bezvýznamný.
• Označujte přechody failoveru ve svém monitoringu, aby lokalita běžící dny na svém záložním uplinku vyvolala tiket — failover, kterého si nikdo nevšimne, je opakující se náklad, ne záchrana.
• Otestujte skutečný kabel, ne jen trasu: vytáhněte konektor primárního a změřte reálný čas přepnutí.

Dostaňte failover pod jednu řídicí rovinu

Dual-WAN failover na jednom MikroTiku je vyřešený problém. Dělat to spolehlivě napříč flotilou — s konzistentní konfigurací a schopností dokázat, že záloha funguje na routeru, na který se nedostanete přes veřejnou IP — je místo, kde většina operátorů prodělává. Centralizovaná, na odchozí straně ukotvená správa tuto mezeru zaceluje.

Spusťte si bezplatnou zkušební verzi MKController