MikroTik dual-WAN-failover voor ISP's

Samenvatting MikroTik dual-WAN-failover houdt een locatie online door verkeer automatisch naar een back-up-uplink te verplaatsen wanneer de primaire link uitvalt. RouterOS geeft u drie bouwstenen — recursieve routing met check-gateway, Netwatch en NAT per WAN — en de juiste combinatie hangt af van hoe snel en hoe slim uw detectie moet zijn. Voor ISP-vloten is het lastigere probleem niet het configuratiefragment, maar bevestigen, over honderden externe locaties achter CGNAT, dat de failover daadwerkelijk werkte. Deze gids behandelt beide.

Wat is MikroTik dual-WAN-failover?

MikroTik dual-WAN-failover is een RouterOS-configuratie die een router twee internet-uplinks geeft — een primaire en een back-up — en het verkeer automatisch naar de back-up verplaatst wanneer de primaire geen pakketten meer doorlaat, en het terugverplaatst wanneer deze hersteld is. Het is niet hetzelfde als load balancing: failover houdt één link inactief als verzekering, terwijl load balancing het verkeer over beide verspreidt. Het doel is continuïteit, niet extra bandbreedte, en daarom is het het standaard redundantiepatroon voor locaties die simpelweg niet uit mogen vallen.

Het mechanisme berust op routekeuze. RouterOS kiest de actieve standaardroute op basis van de laagste administratieve afstand, dus geeft u de primaire een kleinere afstand en de back-up een grotere. Het hele ontwerp komt dan neer op één vraag: hoe besluit de router dat de primaire “down” is en degradeert hij zijn route? Maak die beslissing goed — snel genoeg, maar niet zenuwachtig — en de failover is betrouwbaar. Maak hem verkeerd, en u schakelt ofwel te traag om ofwel fladdert u tussen de links bij elk verloren pakket.

Stap 1 — Breng beide WAN’s in kaart voordat u een route aanraakt

Begin met opschrijven wat elke uplink daadwerkelijk is. Een vaste glasvezel- of PPPoE-primaire met een statische of via PPP toegewezen gateway gedraagt zich anders dan een Starlink- of LTE-back-up die achter Carrier-Grade NAT zit en u een dynamisch adres geeft. Dit is belangrijk omdat recursieve routing alleen werkt met stabiele IP-gateways, niet met dynamische interfacetypes zoals PPPoE of DHCP waar het adres kan veranderen (MikroTik-documentatie — Failover (WAN Backup)). Bepaal welke link primair is, welke back-up, en of er één zijn IP wijzigt bij opnieuw verbinden — dat ene feit bepaalt welke detectiemethode u kunt gebruiken.

Stap 2 — Voeg recursieve standaardroutes toe met check-gateway

De klassieke aanpak gebruikt recursieve routing: in plaats van de standaardroute rechtstreeks naar een next hop te wijzen, wijst u hem naar een probe-doel (bijvoorbeeld een bekende publieke resolver) en voegt u een statische route toe die RouterOS opdraagt dat doel alleen via een specifieke WAN-gateway te bereiken. Vervolgens maakt u twee standaardroutes die recursief over die doelen worden opgelost — de primaire met een kleinere afstand en check-gateway=ping ingeschakeld, de back-up met een grotere afstand (Scoop — Basic ISP Failover with MikroTik).

Het gedrag waar u omheen moet plannen is de timing. Check-gateway deactiveert een route na twee opeenvolgende mislukte checks, en checks lopen ongeveer elke 10 seconden, dus de werkelijke omschakeling ligt rond de 20 tot 30 seconden — en het reageert niet op intermitterend pakketverlies, alleen op een volledig dode gateway (MikroTik-documentatie — Failover (WAN Backup)). Voor veel ISP-klantlocaties is dat acceptabel. Voor spraak- of betaalterminals vaak niet, en daar komt stap 4 in beeld.

Stap 3 — Configureer NAT voor beide uplinks

Een dual-WAN-router heeft een aparte masquerade- (of src-nat-)regel per WAN-interface nodig zodat de op dat moment actieve link het uitgaande verkeer correct vertaalt; een enkele regel die aan één interface is gebonden, verbreekt stilletjes de connectiviteit op het moment dat de failover het verkeer naar de andere link verplaatst. Voeg één masquerade-regel toe in de srcnat-keten voor de primaire out-interface en een tweede voor de back-up. Als u inkomende diensten publiceert, onthoud dan dat dst-nat-regels die aan het adres van de primaire zijn gekoppeld stoppen met werken zodra die link — en zijn publieke IP — verdwijnt. Die inkomende kwetsbaarheid is dezelfde architectonische valkuil die behandeld wordt in onze Starlink-IP-wijzigingen-case, en het is de reden waarom uitgaand-verankerde toegang beter schaalt dan port forwarding. Voor de NAT-grondbeginselen, zie onze gids voor het configureren van NAT op MikroTik.

Stap 4 — Gebruik Netwatch wanneer u snellere of slimmere detectie nodig hebt

Wanneer 20–30 seconden te traag is of u moet handelen op gedegradeerde-maar-levende links, is Netwatch het flexibelere gereedschap. In RouterOS v7 kreeg Netwatch een type-parameter die kan proben met icmp, tcp-conn, http-get, https-get of simple, en u kunt uw eigen check-interval instellen in plaats van te leven met de vaste cadans van check-gateway (MikroTik-documentatie — Failover (WAN Backup)). Elke host heeft een up- en een down-script, zodat u bij de overgang de primaire standaardroute kunt uitschakelen, een waarschuwing kunt activeren of de gebeurtenis kunt loggen.

Veel operators combineren beide: recursieve routing handelt schone linkdood af, terwijl Netwatch de rommeligere gevallen dekt en meldingen verstuurt. Een lang lopende communitythread bespreekt precies deze afweging en is de moeite waard om te lezen voordat u één methode over een vloot standaardiseert (MikroTik-forum — netwatch instead of recursive routing). Wat u ook kiest, houd de configuratie identiek op elke locatie — een vloot van op maat gemaakte failover-scripts is zelf een storing die staat te wachten om te gebeuren.

Stap 5 — Verifieer failover op elke externe locatie

Hier is het deel dat de configuratietutorials overslaan. De routes toevoegen op één testrouter is eenvoudig; bewijzen dat failover werkt op honderden uitgerolde CPE’s is het echte ISP-probleem — en het wordt moeilijker wanneer de back-up-link Starlink of LTE achter CGNAT is, omdat het apparaat na de omschakeling vaak geen bereikbare publieke IP heeft om het via te beheren. Als u failover alleen kunt bevestigen door te wachten tot een klant belt, hebt u eigenlijk geen failover; u hebt een script waarvan u hoopt dat het draait.

Hier verandert gecentraliseerd beheer de economie. MKController houdt elke router bereikbaar via een geauthenticeerde uitgaande tunnel, zodat u kunt bevestigen dat het back-up-pad verkeer draagt, de failover-overgang in monitoring kunt volgen en een gecorrigeerde configuratie kunt pushen — zonder afhankelijk te zijn van een publieke IP die op de back-up-link misschien niet bestaat. Combineer dat met telemetrie: onze gidsen over MikroTik op afstand monitoren met Zabbix en SNMP-monitoring voor MikroTik laten zien hoe u op de failover-gebeurtenis zelf alarmeert, zodat een stille omschakeling naar de dure back-up-link nooit onopgemerkt blijft.

Tips

• Houd de check-gateway-probe van de back-up-link gericht op een doel dat u via die link bereikt, niet via de primaire, anders is uw test betekenisloos.
• Tag failover-overgangen in uw monitoring zodat een locatie die dagenlang op zijn back-up-uplink draait een ticket aanmaakt — failover die niemand opmerkt is een terugkerende kostenpost, geen redding.
• Test de daadwerkelijke kabel, niet alleen de route: trek de connector van de primaire eruit en meet de werkelijke omschakeltijd.

Breng failover onder één control plane

Dual-WAN-failover op een enkele MikroTik is een opgelost probleem. Het betrouwbaar doen over een vloot — met consistente configuratie en het vermogen om te bewijzen dat de back-up werkt op een router die u niet via publieke IP kunt bereiken — is waar de meeste operators geld verliezen. Gecentraliseerd, uitgaand-verankerd beheer dicht dat gat.

Start uw gratis MKController-proefperiode