MikroTik dual-WAN-failover til ISP'er

Resumé MikroTik dual-WAN-failover holder et site online ved automatisk at flytte trafikken til et backup-uplink, når det primære link svigter. RouterOS giver dig tre byggesten — rekursiv routing med check-gateway, Netwatch og NAT pr. WAN — og den rigtige kombination afhænger af, hvor hurtig og hvor smart din detektion skal være. For ISP-flåder er det sværere problem ikke konfigurationsstumpen, men at bekræfte på tværs af hundredvis af fjernsites bag CGNAT, at failover faktisk virkede. Denne guide dækker begge dele.

Hvad Er MikroTik dual-WAN-failover?

MikroTik dual-WAN-failover er en RouterOS-konfiguration, der giver en router to internet-uplinks — et primært og et backup — og automatisk flytter trafikken til backuppet, når det primære holder op med at sende pakker, og flytter den tilbage igen, når det kommer sig. Det er ikke det samme som load balancing: failover holder ét link inaktivt som forsikring, mens load balancing fordeler trafikken over begge. Målet er kontinuitet, ikke ekstra båndbredde, og derfor er det standard-redundansmønstret for sites, der simpelthen ikke må gå mørke.

Mekanismen hviler på rutevalg. RouterOS vælger den aktive standardrute efter laveste administrative afstand, så du giver det primære en mindre afstand og backuppet en større. Hele designet reduceres så til ét spørgsmål: hvordan beslutter routeren, at det primære er “nede”, og nedgraderer dets rute? Træf den beslutning rigtigt — hurtigt nok, men ikke nervøst — og failover er pålidelig. Tag fejl, og du skifter enten for langsomt eller flapper mellem links ved hvert tabt pakke.

Trin 1 — Kortlæg de to WAN’er, før du rører en rute

Begynd med at skrive ned, hvad hvert uplink faktisk er. Et fast fiber- eller PPPoE-primært med en statisk eller PPP-tildelt gateway opfører sig anderledes end et Starlink- eller LTE-backup, der sidder bag Carrier-Grade NAT og giver dig en dynamisk adresse. Det betyder noget, fordi rekursiv routing kun virker med stabile IP-gateways, ikke med dynamiske interfacetyper som PPPoE eller DHCP, hvor adressen kan ændre sig (MikroTik-dokumentation — Failover (WAN Backup)). Beslut hvilket link der er primært, hvilket der er backup, og om nogen af dem ændrer deres IP ved genforbindelse — det ene faktum dikterer, hvilken detektionsmetode du kan bruge.

Trin 2 — Tilføj rekursive standardruter med check-gateway

Den klassiske tilgang bruger rekursiv routing: i stedet for at pege standardruten direkte på et next hop peger du den på et probe-mål (for eksempel en velkendt offentlig resolver) og tilføjer en statisk rute, der fortæller RouterOS at nå det mål kun gennem en bestemt WAN-gateway. Du opretter så to standardruter, der opløses rekursivt over disse mål — det primære med en mindre afstand og check-gateway=ping aktiveret, backuppet med en større afstand (Scoop — Basic ISP Failover with MikroTik).

Den adfærd, man skal planlægge omkring, er timing. Check-gateway deaktiverer en rute efter to på hinanden følgende mislykkede tjek, og tjek kører cirka hvert 10. sekund, så den reelle omskiftning lander omkring 20 til 30 sekunder — og den reagerer ikke på intermitterende pakketab, kun på en helt død gateway (MikroTik-dokumentation — Failover (WAN Backup)). For mange ISP-kundesites er det acceptabelt. For tale- eller betalingsterminaler ofte ikke, og det er her, Trin 4 kommer ind.

Trin 3 — Konfigurér NAT for begge uplinks

En dual-WAN-router har brug for en separat masquerade- (eller src-nat-)regel pr. WAN-interface, så det link, der er aktivt, oversætter udgående trafik korrekt; en enkelt regel bundet til ét interface vil stille bryde forbindelsen i samme øjeblik, failover flytter trafikken til det andet link. Tilføj én masquerade-regel i srcnat-kæden for det primære out-interface og en anden for backuppet. Hvis du publicerer indgående tjenester, så husk, at dst-nat-regler bundet til det primæres adresse holder op med at virke, så snart det link — og dets offentlige IP — forsvinder. Den indgående skrøbelighed er den samme arkitektoniske fælde, der behandles i vores Starlink-IP-ændringer-case, og det er derfor, udgående-forankret adgang skalerer bedre end portviderestilling. For NAT-grundlaget, se vores guide til at konfigurere NAT på MikroTik.

Trin 4 — Brug Netwatch, når du har brug for hurtigere eller smartere detektion

Når 20–30 sekunder er for langsomt, eller du skal handle på forringede-men-levende links, er Netwatch det mere fleksible værktøj. I RouterOS v7 fik Netwatch en type-parameter, der kan probe med icmp, tcp-conn, http-get, https-get eller simple, og du kan sætte dit eget tjekinterval i stedet for at leve med check-gateways faste kadence (MikroTik-dokumentation — Failover (WAN Backup)). Hver host har et up- og et down-script, så du kan deaktivere den primære standardrute, udløse en alarm eller logge hændelsen ved overgang.

Mange operatører kombinerer de to: rekursiv routing håndterer ren link-død, mens Netwatch dækker de mere rodede tilfælde og sender notifikationer. En langvarig community-tråd debatterer netop denne afvejning og er værd at læse, før du standardiserer én metode på tværs af en flåde (MikroTik-forum — netwatch instead of recursive routing). Uanset hvad du vælger, så hold konfigurationen identisk på hvert site — en flåde af skræddersyede failover-scripts er i sig selv et nedbrud, der bare venter på at ske.

Trin 5 — Verificér failover på hvert fjernsite

Her er den del, konfigurationstutorials springer over. At tilføje ruterne på én bænk-router er nemt; at bevise, at failover virker på hundredvis af udrullede CPE’er, er det egentlige ISP-problem — og det bliver sværere, når backup-linket er Starlink eller LTE bag CGNAT, fordi enheden ofte ikke har nogen tilgængelig offentlig IP at administrere den igennem, efter den har skiftet over. Hvis du kun kan bekræfte failover ved at vente på, at en kunde ringer, har du ikke rigtig failover; du har et script, du håber kører.

Her ændrer centraliseret administration økonomien. MKController holder hver router tilgængelig gennem en autentificeret udgående tunnel, så du kan bekræfte, at backupstien bærer trafik, følge failover-overgangen i monitorering og skubbe en rettet konfiguration ud — uden at afhænge af en offentlig IP, der måske ikke findes på backup-linket. Kombinér det med telemetri: vores guides om fjernovervågning af MikroTik med Zabbix og SNMP-overvågning til MikroTik viser, hvordan du alarmerer på selve failover-hændelsen, så et stille skift til det dyre backup-link aldrig går ubemærket hen.

Tips

• Hold backup-linkets check-gateway-probe rettet mod et mål, du når gennem det link, ikke gennem det primære, ellers er din test meningsløs.
• Tag failover-overgange i din monitorering, så et site, der kører i dagevis på sit backup-uplink, udløser en sag — failover, ingen lægger mærke til, er en tilbagevendende omkostning, ikke en redning.
• Test det faktiske kabel, ikke bare ruten: træk det primæres stik ud, og tag tid på den reelle omskiftning.

Få failover under ét kontrolplan

Dual-WAN-failover på en enkelt MikroTik er et løst problem. At gøre det pålideligt på tværs af en flåde — med konsistent konfiguration og evnen til at bevise, at backuppet virker på en router, du ikke kan nå via offentlig IP — er der, hvor de fleste operatører taber penge. Centraliseret, udgående-forankret administration lukker det hul.

Start din gratis MKController-prøveperiode