MikroTik Dual-WAN-failover för ISP

Sammanfattning MikroTik dual-WAN-failover håller en plats online genom att automatiskt flytta trafiken till en reservuplänk när den primära länken slutar fungera. RouterOS ger dig tre byggstenar — rekursiv routing med check-gateway, Netwatch och NAT per WAN — och rätt kombination beror på hur snabb och hur smart din detektering måste vara. För ISP-flottor är det svårare problemet inte konfigurationssnutten, utan att bekräfta över hundratals fjärrplatser bakom CGNAT att failover faktiskt fungerade. Den här guiden täcker båda.

Vad Är MikroTik Dual-WAN-failover?

MikroTik dual-WAN-failover är en RouterOS-konfiguration som ger en router två internetuplänkar — en primär och en reserv — och automatiskt flyttar trafiken till reserven när den primära slutar släppa igenom paket, och flyttar tillbaka den när den återhämtar sig. Det är inte samma sak som lastbalansering: failover håller en länk vilande som försäkring, medan lastbalansering sprider trafiken över båda. Målet är kontinuitet, inte extra bandbredd, vilket är varför det är standardmönstret för redundans för platser som helt enkelt inte får slockna.

Mekanismen vilar på ruttval. RouterOS väljer den aktiva standardrutten efter lägst administrativ distans, så du ger den primära en mindre distans och reserven en större. Hela designen reduceras sedan till en fråga: hur avgör routern att den primära är nere och nedgraderar dess rutt? Fatta det beslutet rätt — snabbt nog men inte nervöst — och failover är tillförlitlig. Gör det fel och du växlar antingen för långsamt eller fladdrar mellan länkarna vid varje paketförlust.

Steg 1 — Kartlägg de två WAN-länkarna innan du rör en rutt

Börja med att skriva ner vad varje uplänk faktiskt är. En fast fiber- eller PPPoE-primär med en statisk eller PPP-tilldelad gateway beter sig annorlunda än en Starlink- eller LTE-reserv som sitter bakom Carrier-Grade NAT och ger dig en dynamisk adress. Detta spelar roll eftersom rekursiv routing endast fungerar med stabila IP-gateways, inte med dynamiska gränssnittstyper som PPPoE eller DHCP där adressen kan ändras (MikroTik-dokumentation — Failover (WAN Backup)). Bestäm vilken länk som är primär, vilken som är reserv och om någon byter sin IP vid återanslutning — det enda faktumet avgör vilken detekteringsmetod du kan använda.

Steg 2 — Lägg till rekursiva standardrutter med check-gateway

Det klassiska tillvägagångssättet använder rekursiv routing: i stället för att peka standardrutten direkt på ett nästa hopp pekar du den på ett probmål (till exempel en välkänd publik resolver) och lägger till en statisk rutt som säger åt RouterOS att nå det målet endast via en specifik WAN-gateway. Du skapar sedan två standardrutter som rekursivt löses över dessa mål — den primära med mindre distans och aktiverat check-gateway=ping, reserven med större distans (Scoop — Basic ISP Failover with MikroTik).

Beteendet att planera kring är timing. Check-gateway inaktiverar en rutt efter två på varandra följande misslyckade kontroller, och kontroller körs ungefär var tionde sekund, så den verkliga växlingen landar runt 20 till 30 sekunder — och den reagerar inte på intermittent paketförlust, bara på en helt död gateway (MikroTik-dokumentation — Failover (WAN Backup)). För många ISP-kundplatser är det acceptabelt. För röst- eller betalterminaler är det ofta inte det, och det är där Steg 4 kommer in.

Steg 3 — Konfigurera NAT för båda uplänkarna

En dual-WAN-router behöver en separat masquerade- (eller src-nat-)regel per WAN-gränssnitt så att den länk som är aktiv översätter utgående trafik korrekt; en enda regel bunden till ett gränssnitt bryter tyst anslutningen i det ögonblick failover flyttar trafiken till den andra länken. Lägg till en masquerade-regel i srcnat-kedjan för det primära out-interface och en andra för reserven. Om du publicerar inkommande tjänster, kom ihåg att dst-nat-regler bundna till den primäras adress slutar fungera när den länken — och dess publika IP — försvinner. Den inkommande sårbarheten är samma arkitektoniska fälla som behandlas i vårt fall om Starlink-IP-ändringar, och det är därför utgångsförankrad åtkomst skalar bättre än portvidarebefordran. För NAT-grunderna, se vår guide för att konfigurera NAT på MikroTik.

Steg 4 — Använd Netwatch när du behöver snabbare eller smartare detektering

När 20–30 sekunder är för långsamt eller du behöver agera på degraderade-men-levande länkar är Netwatch det mer flexibla verktyget. I RouterOS v7 fick Netwatch en type-parameter som kan proba med icmp, tcp-conn, http-get, https-get eller simple, och du kan sätta ditt eget kontrollintervall i stället för att leva med check-gateways fasta kadens (MikroTik-dokumentation — Failover (WAN Backup)). Varje värd har ett up- och ett down-skript, så du kan inaktivera den primära standardrutten, utlösa ett larm eller logga händelsen vid övergången.

Många operatörer kombinerar de två: rekursiv routing hanterar ren länkdöd, medan Netwatch täcker de stökigare fallen och skickar aviseringar. En långvarig community-tråd debatterar exakt denna avvägning och är värd att läsa innan du standardiserar på en metod över en flotta (MikroTik-forum — netwatch instead of recursive routing). Vad du än väljer, håll konfigurationen identisk på varje plats — en flotta av skräddarsydda failover-skript är ett eget avbrott som bara väntar på att hända.

Steg 5 — Verifiera failover på varje fjärrplats

Här är den del som konfigurationshandledningarna hoppar över. Att lägga till rutterna på en bänkrouter är enkelt; att bevisa att failover fungerar på hundratals utplacerade CPE:er är det verkliga ISP-problemet — och det blir svårare när reservlänken är Starlink eller LTE bakom CGNAT, eftersom enheten ofta inte har en nåbar publik IP att hantera den genom efter att den har växlat. Om du bara kan bekräfta failover genom att vänta på att en kund ringer har du egentligen inte failover; du har ett skript som du hoppas körs.

Här ändrar centraliserad hantering ekonomin. MKController håller varje router nåbar genom en autentiserad utgående tunnel, så att du kan bekräfta att reservvägen bär trafik, observera failover-övergången i övervakning och pusha en korrigerad konfiguration — utan att vara beroende av en publik IP som kanske inte finns på reservlänken. Para det med telemetri: våra guider om fjärrövervakning av MikroTik med Zabbix och SNMP-övervakning för MikroTik visar hur du larmar på själva failover-händelsen, så att en tyst växling till den dyra reservlänken aldrig går obemärkt förbi.

Tips

• Håll reservlänkens check-gateway-prob riktad mot ett mål du når via den länken, inte via den primära, annars är ditt test meningslöst.
• Tagga failover-övergångar i din övervakning så att en plats som kör i dagar på sin reservuplänk genererar ett ärende — failover som ingen märker är en återkommande kostnad, inte en räddning.
• Testa den verkliga kabeln, inte bara rutten: dra ut den primäras kontakt och ta tid på den verkliga växlingen.

För failover under ett kontrollplan

Dual-WAN-failover på en enda MikroTik är ett löst problem. Att göra det tillförlitligt över en flotta — med konsekvent konfiguration och förmågan att bevisa att reserven fungerar på en router du inte kan nå via publik IP — är där de flesta operatörer förlorar pengar. Centraliserad, utgångsförankrad hantering täpper till det gapet.

Starta din kostnadsfria MKController-provperiod