Dual WAN e failover: garantire la continuità Internet in azienda

Per un'azienda che lavora su gestionali in cloud, VoIP e posta elettronica, un'ora di Internet giù è un'ora di attività ferma. Una connessione singola, per quanto buona, resta un singolo punto di guasto: basta un taglio fibra o un guasto della centrale per fermare tutto. Il dual WAN — due connessioni gestite insieme da un router — è la risposta standard al problema della continuità.

Failover vs load balancing: due obiettivi diversi

Avere due linee può servire a due scopi distinti, spesso confusi:

• Failover: una linea è primaria, l'altra resta in standby e subentra automaticamente solo quando la primaria cade. Obiettivo: continuità, non più banda.
• Load balancing: il traffico viene distribuito su entrambe le linee contemporaneamente per sommare banda. Obiettivo: più capacità, con la ridondanza come effetto collaterale.

Per la business continuity il modello giusto è il failover (eventualmente in combinazione con il bilanciamento). La domanda chiave è: "se cade una linea, l'azienda deve solo restare connessa o anche mantenere tutta la banda?".

Scegliere le tecnologie: diversità è tutto

L'errore più comune è prendere due linee dallo stesso operatore sulla stessa infrastruttura: se si guasta la centrale o si taglia la fibra condivisa, cadono entrambe insieme. La ridondanza vera richiede diversità:

• Fibra FTTH + FWA 5G: tecnologie e percorsi fisici diversi; il backup radio non dipende dalla stessa tratta in fibra.
• Due operatori distinti: riduce il rischio che un guasto di rete a monte le abbatta entrambe.
• Fibra + connettività mobile come ultima risorsa per i servizi essenziali.

Più i due percorsi sono indipendenti (fisicamente e come operatore), più la ridondanza è reale.

Cosa rende la commutazione "trasparente"

Un failover che fa cadere tutte le sessioni quando commuta è poco utile per VoIP e applicazioni cloud. Per renderlo trasparente servono alcuni elementi:

• Health check attivi: il router non deve fidarsi solo dello stato della porta, ma testare la raggiungibilità reale (ping/HTTP verso target esterni). Una linea può essere "up" fisicamente ma non passare traffico.
• Tempi di rilevamento bassi: pochi secondi per accorgersi del guasto e commutare.
• Gestione delle sessioni: in failover puro le connessioni TCP attive si rinegoziano sulla nuova linea; per i servizi critici si valuta una VPN o SD-WAN che mantenga la sessione.

Il problema dell'IP pubblico

Quando si commuta sulla linea di backup, cambia l'IP pubblico di uscita. Questo impatta:

• VPN site-to-site: vanno configurate per reggere il cambio di IP (DDNS o, meglio, IP statico su entrambe le linee).
• Servizi pubblicati (mail server, accessi remoti): se dipendono da un IP fisso, vanno gestiti con DNS aggiornabili o failover applicativo.
• VoIP: il trunk SIP deve ri-registrarsi sul nuovo IP; un centralino ben configurato lo fa in automatico.

Per chi pubblica servizi, l'ideale è un IP statico su entrambe le WAN o, in scenari avanzati, l'annuncio del proprio blocco IP via BGP — soluzione da ISP, non da PMI tipica.

SD-WAN: il livello successivo

Per chi ha più sedi e molte applicazioni cloud, l'SD-WAN porta il dual WAN a un livello superiore: instrada dinamicamente ogni applicazione sulla linea migliore in base a latenza e perdita di pacchetti, mantenendo le sessioni durante la commutazione grazie a tunnel sovrapposti. È la scelta quando il semplice failover non basta a garantire qualità costante.

Dimensionare il backup

Il backup non deve necessariamente eguagliare la primaria, ma reggere i servizi essenziali:

• Stima la banda minima per VoIP, gestionale e posta in caso di failover.
• Verifica che la linea di backup, anche se più lenta, sostenga quel carico.
• Testa periodicamente il failover staccando la primaria: un backup mai provato spesso non funziona quando serve.

In sintesi

La continuità Internet in azienda si costruisce con due linee diverse per tecnologia e operatore, gestite in failover con health check attivi e tempi di commutazione bassi. Il nodo da risolvere è il cambio di IP pubblico, che impatta VPN, servizi pubblicati e VoIP: si gestisce con IP statico, DDNS o SD-WAN. E vale una regola sopra tutte: un failover che non viene testato regolarmente è solo un'illusione di ridondanza.