Failover dual-WAN MikroTik per ISP

Riepilogo Il failover dual-WAN MikroTik mantiene un sito online spostando automaticamente il traffico su un uplink di backup quando il collegamento primario si guasta. RouterOS ti offre tre elementi costitutivi — routing ricorsivo con check-gateway, Netwatch e NAT per WAN — e la combinazione giusta dipende da quanto veloce e quanto intelligente deve essere il tuo rilevamento. Per le flotte ISP il problema più difficile non è lo snippet di configurazione, ma confermare, su centinaia di siti remoti dietro CGNAT, che il failover abbia davvero funzionato. Questa guida copre entrambi.

Cos’è Il Failover Dual-WAN MikroTik?

Il failover dual-WAN MikroTik è una configurazione RouterOS che fornisce a un router due uplink internet — uno primario e uno di backup — e sposta automaticamente il traffico su quello di backup quando il primario smette di far passare i pacchetti, per poi riportarlo indietro quando si riprende. Non è la stessa cosa del bilanciamento del carico: il failover tiene un collegamento inattivo come assicurazione, mentre il bilanciamento del carico distribuisce il traffico su entrambi. L’obiettivo è la continuità, non la larghezza di banda aggiuntiva, ed è per questo che è il pattern di ridondanza predefinito per i siti che semplicemente non possono spegnersi.

Il meccanismo si basa sulla selezione della rotta. RouterOS sceglie la rotta predefinita attiva in base alla distanza amministrativa più bassa, quindi assegni al primario una distanza minore e al backup una maggiore. L’intero progetto si riduce allora a una sola domanda: come decide il router che il primario è «giù» e ne declassa la rotta? Prendi bene questa decisione — abbastanza veloce, ma non nervosa — e il failover è affidabile. Sbagliala e o esegui il failover troppo lentamente o oscilli tra i collegamenti a ogni pacchetto perso.

Passo 1 — Mappa entrambe le WAN prima di toccare una rotta

Inizia annotando cosa sia realmente ciascun uplink. Un primario in fibra fissa o PPPoE con gateway statico o assegnato via PPP si comporta diversamente da un backup Starlink o LTE che sta dietro Carrier-Grade NAT e ti fornisce un indirizzo dinamico. Questo conta perché il routing ricorsivo funziona solo con gateway IP stabili, non con tipi di interfaccia dinamici come PPPoE o DHCP dove l’indirizzo può cambiare (Documentazione MikroTik — Failover (WAN Backup)). Decidi quale collegamento è primario, quale di backup e se uno dei due cambia il proprio IP alla riconnessione — questo singolo fatto detta quale metodo di rilevamento puoi usare.

Passo 2 — Aggiungi rotte predefinite ricorsive con check-gateway

L’approccio classico usa il routing ricorsivo: invece di puntare la rotta predefinita direttamente a un next hop, la punti a un target di sonda (per esempio un noto resolver pubblico) e aggiungi una rotta statica che dice a RouterOS di raggiungere quel target solo attraverso uno specifico gateway WAN. Poi crei due rotte predefinite risolte ricorsivamente su quei target — la primaria con distanza minore e check-gateway=ping abilitato, quella di backup con distanza maggiore (Scoop — Basic ISP Failover with MikroTik).

Il comportamento attorno a cui pianificare è la tempistica. Check-gateway disattiva una rotta dopo due controlli falliti consecutivi, e i controlli vengono eseguiti all’incirca ogni 10 secondi, quindi lo switch reale si attesta intorno ai 20-30 secondi — e non reagisce alla perdita intermittente di pacchetti, solo a un gateway completamente morto (Documentazione MikroTik — Failover (WAN Backup)). Per molti siti dei clienti ISP è accettabile. Per terminali voce o di pagamento spesso non lo è, ed è qui che entra in gioco il Passo 4.

Passo 3 — Configura il NAT per entrambi gli uplink

Un router dual-WAN ha bisogno di una regola masquerade (o src-nat) separata per interfaccia WAN così che il collegamento attivo in quel momento traduca correttamente il traffico in uscita; una singola regola legata a un’interfaccia interromperà silenziosamente la connettività nel momento in cui il failover sposta il traffico sull’altro collegamento. Aggiungi una regola masquerade nella catena srcnat per l’out-interface primaria e una seconda per il backup. Se pubblichi servizi in entrata, ricorda che le regole dst-nat legate all’indirizzo del primario smettono di funzionare quando quel collegamento — e il suo IP pubblico — scompare. Questa fragilità in entrata è la stessa trappola architettonica trattata nel nostro caso sui cambi di IP Starlink, ed è il motivo per cui l’accesso ancorato in uscita scala meglio del port forwarding. Per le basi del NAT, vedi la nostra guida alla configurazione del NAT su MikroTik.

Passo 4 — Usa Netwatch quando ti serve un rilevamento più rapido o intelligente

Quando 20-30 secondi sono troppo lenti o devi agire su collegamenti degradati-ma-vivi, Netwatch è lo strumento più flessibile. In RouterOS v7, Netwatch ha guadagnato un parametro type che può sondare con icmp, tcp-conn, http-get, https-get o simple, e puoi impostare il tuo intervallo di controllo invece di convivere con la cadenza fissa di check-gateway (Documentazione MikroTik — Failover (WAN Backup)). Ogni host ha uno script up e uno down, così alla transizione puoi disabilitare la rotta predefinita primaria, generare un allarme o registrare l’evento.

Molti operatori combinano i due: il routing ricorsivo gestisce la morte pulita del collegamento, mentre Netwatch copre i casi più caotici e invia notifiche. Un thread della community di lunga data dibatte esattamente questo compromesso e vale la pena leggerlo prima di standardizzare un metodo su un’intera flotta (Forum MikroTik — netwatch instead of recursive routing). Qualunque cosa tu scelga, mantieni la configurazione identica su ogni sito — una flotta di script di failover su misura è essa stessa un’interruzione in attesa di accadere.

Passo 5 — Verifica il failover su ogni sito remoto

Ecco la parte che i tutorial di configurazione saltano. Aggiungere le rotte su un router da banco è facile; dimostrare che il failover funziona su centinaia di CPE distribuiti è il vero problema ISP — e diventa più difficile quando il collegamento di backup è Starlink o LTE dietro CGNAT, perché dopo il failover il dispositivo spesso non ha un IP pubblico raggiungibile per gestirlo. Se puoi confermare il failover solo aspettando che un cliente chiami, non hai davvero un failover; hai uno script che speri venga eseguito.

È qui che la gestione centralizzata cambia l’economia. MKController mantiene ogni router raggiungibile attraverso un tunnel in uscita autenticato, così puoi confermare che il percorso di backup porti traffico, osservare la transizione di failover nel monitoraggio e inviare una configurazione corretta — senza dipendere da un IP pubblico che sul collegamento di backup potrebbe non esistere. Abbinalo alla telemetria: le nostre guide sul monitoraggio remoto di MikroTik con Zabbix e sul monitoraggio SNMP per MikroTik mostrano come allertare sull’evento di failover stesso, così che uno switch silenzioso verso il costoso collegamento di backup non passi mai inosservato.

Consigli

• Mantieni la sonda check-gateway del collegamento di backup puntata su un target che raggiungi attraverso quel collegamento, non attraverso il primario, altrimenti il tuo test è privo di significato.
• Etichetta le transizioni di failover nel tuo monitoraggio così che un sito che gira da giorni sul suo uplink di backup apra un ticket — un failover che nessuno nota è un costo ricorrente, non un salvataggio.
• Testa il cavo reale, non solo la rotta: stacca il connettore del primario e cronometra lo switch reale.

Porta il failover sotto un unico piano di controllo

Il failover dual-WAN su un singolo MikroTik è un problema risolto. Farlo in modo affidabile su un’intera flotta — con configurazione coerente e la capacità di dimostrare che il backup funziona su un router che non puoi raggiungere via IP pubblico — è il punto in cui la maggior parte degli operatori perde denaro. La gestione centralizzata e ancorata in uscita colma questo divario.

Inizia la tua prova gratuita di MKController