MikroTik dual-WAN-failover for ISP-er

Sammendrag MikroTik dual-WAN-failover holder et nettsted på nett ved automatisk å flytte trafikk til en reserve-opplink når den primære linken svikter. RouterOS gir deg tre byggeklosser — rekursiv ruting med check-gateway, Netwatch og NAT per WAN — og den riktige kombinasjonen avhenger av hvor raskt og hvor smart deteksjonen din må være. For ISP-flater er det vanskeligere problemet ikke konfigurasjonssnutten, men å bekrefte, på tvers av hundrevis av eksterne nettsteder bak CGNAT, at failover faktisk fungerte. Denne veiledningen dekker begge.

Hva er MikroTik dual-WAN-failover?

MikroTik dual-WAN-failover er en RouterOS-konfigurasjon som gir en ruter to internett-opplinker — en primær og en reserve — og automatisk flytter trafikk til reserven når den primære slutter å slippe gjennom pakker, for så å flytte tilbake når den kommer seg. Det er ikke det samme som lastbalansering: failover holder én link inaktiv som forsikring, mens lastbalansering sprer trafikk over begge. Målet er kontinuitet, ikke ekstra båndbredde, og det er derfor det er standard redundansmønster for nettsteder som rett og slett ikke kan gå mørke.

Mekanismen hviler på rutevalg. RouterOS velger den aktive standardruten etter laveste administrative distanse, så du gir den primære en mindre distanse og reserven en større. Hele utformingen koker da ned til ett spørsmål: hvordan avgjør ruteren at den primære er «nede» og nedgraderer ruten dens? Ta denne avgjørelsen riktig — raskt nok, men ikke nervøst — og failover er pålitelig. Gjør den feil, og du enten kobler om for sent eller flagrer mellom linkene ved hvert tapt pakke.

Steg 1 — Kartlegg de to WAN-ene før du rører en rute

Begynn med å skrive ned hva hver opplink faktisk er. En fast fiber- eller PPPoE-primær med en statisk eller PPP-tildelt gateway oppfører seg annerledes enn en Starlink- eller LTE-reserve som sitter bak Carrier-Grade NAT og gir deg en dynamisk adresse. Dette betyr noe fordi rekursiv ruting bare fungerer med stabile IP-gatewayer, ikke med dynamiske grensesnitt-typer som PPPoE eller DHCP der adressen kan endre seg (MikroTik-dokumentasjon — Failover (WAN Backup)). Avgjør hvilken link som er primær, hvilken som er reserve, og om noen av dem endrer IP-en sin ved gjentilkobling — dette ene faktumet bestemmer hvilken deteksjonsmetode du kan bruke.

Steg 2 — Legg til rekursive standardruter med check-gateway

Den klassiske tilnærmingen bruker rekursiv ruting: i stedet for å peke standardruten direkte mot et neste hopp, peker du den mot et prøvemål (for eksempel en velkjent offentlig resolver) og legger til en statisk rute som forteller RouterOS å nå det målet bare gjennom en bestemt WAN-gateway. Deretter oppretter du to standardruter som løses rekursivt over disse målene — den primære med mindre distanse og check-gateway=ping aktivert, reserven med større distanse (Scoop — Basic ISP Failover with MikroTik).

Atferden du må planlegge rundt er timing. Check-gateway deaktiverer en rute etter to påfølgende mislykkede sjekker, og sjekkene kjører omtrent hvert 10. sekund, så reell omkobling lander rundt 20 til 30 sekunder — og den reagerer ikke på sporadisk pakketap, bare på en helt død gateway (MikroTik-dokumentasjon — Failover (WAN Backup)). For mange ISP-kundenettsteder er det akseptabelt. For tale- eller betalingsterminaler er det ofte ikke det, og det er der steg 4 kommer inn.

Steg 3 — Konfigurer NAT for begge opplinkene

En dual-WAN-ruter trenger en separat masquerade- (eller src-nat-)regel per WAN-grensesnitt slik at den til enhver tid aktive linken oversetter utgående trafikk korrekt; en enkelt regel bundet til ett grensesnitt vil stille ødelegge tilkoblingen i det øyeblikket failover flytter trafikk til den andre linken. Legg til én masquerade-regel i srcnat-kjeden for den primære out-interface og en andre for reserven. Hvis du publiserer noen innkommende tjenester, husk at dst-nat-regler knyttet til den primæres adresse slutter å fungere når den linken — og dens offentlige IP — forsvinner. Den innkommende skjørheten er den samme arkitektoniske fellen som dekkes i vår Starlink-IP-endringer-sak, og det er derfor utgående-forankret tilgang skalerer bedre enn portvideresending. For NAT-grunnlaget, se vår guide for å konfigurere NAT på MikroTik.

Steg 4 — Bruk Netwatch når du trenger raskere eller smartere deteksjon

Når 20–30 sekunder er for tregt eller du må handle på forringede-men-levende linker, er Netwatch det mer fleksible verktøyet. I RouterOS v7 fikk Netwatch en type-parameter som kan prøve med icmp, tcp-conn, http-get, https-get eller simple, og du kan sette ditt eget sjekkintervall i stedet for å leve med check-gatewayens faste takt (MikroTik-dokumentasjon — Failover (WAN Backup)). Hver vert har et up- og et down-skript, så du kan deaktivere den primære standardruten, utløse et varsel eller logge hendelsen ved overgang.

Mange operatører kombinerer de to: rekursiv ruting håndterer ren linkdød, mens Netwatch dekker de rotete tilfellene og sender varsler. En langvarig fellesskapstråd diskuterer akkurat denne avveiningen og er verdt å lese før du standardiserer på én metode på tvers av en flate (MikroTik-forum — netwatch instead of recursive routing). Uansett hva du velger, hold konfigurasjonen identisk på hvert nettsted — en flate av skreddersydde failover-skript er sitt eget avbrudd som venter på å skje.

Steg 5 — Verifiser failover på hvert eksternt nettsted

Her er delen konfigurasjonsveiledningene hopper over. Å legge til rutene på én benkeruter er enkelt; å bevise at failover fungerer på hundrevis av utplasserte CPE-er er det virkelige ISP-problemet — og det blir vanskeligere når reservelinken er Starlink eller LTE bak CGNAT, fordi enheten ofte ikke har noen tilgjengelig offentlig IP å administrere den gjennom etter at den har koblet om. Hvis du bare kan bekrefte failover ved å vente på at en kunde ringer, har du egentlig ikke failover; du har et skript du håper kjører.

Det er her sentralisert administrasjon endrer økonomien. MKController holder hver ruter tilgjengelig gjennom en autentisert utgående tunnel, slik at du kan bekrefte at reserveveien bærer trafikk, se failover-overgangen i overvåkningen og pushe en korrigert konfigurasjon — uten å være avhengig av en offentlig IP som kanskje ikke finnes på reservelinken. Kombiner det med telemetri: våre guider om ekstern overvåkning av MikroTik med Zabbix og SNMP-overvåkning for MikroTik viser hvordan du varsler om selve failover-hendelsen, slik at en stille omkobling til den dyre reservelinken aldri går ubemerket hen.

Tips

• Hold reservelinkens check-gateway-prøve pekt mot et mål du når gjennom den linken, ikke gjennom den primære, ellers er testen din meningsløs.
• Merk failover-overganger i overvåkningen din slik at et nettsted som kjører i dagevis på reserve-opplinken sin oppretter en sak — failover som ingen legger merke til er en tilbakevendende kostnad, ikke en redning.
• Test selve kabelen, ikke bare ruten: trekk ut den primæres kontakt og ta tiden på den reelle omkoblingen.

Få failover under ett kontrollplan

Dual-WAN-failover på en enkelt MikroTik er et løst problem. Å gjøre det pålitelig på tvers av en flate — med konsistent konfigurasjon og evnen til å bevise at reserven fungerer på en ruter du ikke kan nå via offentlig IP — er der de fleste operatører taper penger. Sentralisert, utgående-forankret administrasjon lukker det gapet.

Start din gratis MKController-prøveperiode