Un FortiGate con due uplink sa già fare failover senza SD-WAN: bastano due default route e un link monitor. SD-WAN serve quando quella granularità non basta, cioè quando vuoi che una certa applicazione resti sulla linea buona finché la qualità regge e che tutto il resto si bilanci altrove. Non è una licenza separata né un prodotto diverso: è un modo di riorganizzare gli uplink, e cambia soprattutto chi decide l’interfaccia di uscita di un pacchetto.

Underlay, overlay e il ruolo del routing

Fortinet descrive il design SD-WAN su cinque pilastri, e conviene tenerli separati. L’underlay sono i trasporti fisici: broadband, MPLS, LTE 4G/5G. Per ciascuno servono banda, qualità attesa in termini di perdita, latenza e jitter, e costo: sono i numeri con cui poi tari le soglie. L’overlay sono i tunnel IPsec site-to-site che interconnettono filiali, datacenter e cloud, di solito in hub-and-spoke.

Il pilastro che si fraintende più spesso è il routing. SD-WAN non sostituisce la tabella di routing: la usa. Il routing tradizionale costruisce l’elenco di tutti i percorsi possibili verso una destinazione, su underlay e overlay, e il FortiGate li bilancia in ECMP; le regole SD-WAN scelgono quale di quei percorsi usare. Il corollario operativo è che un membro senza rotta valida verso la destinazione non verrà mai usato, per quante regole tu scriva. Restano poi la security, cioè le policy e i profili NGFW applicati al traffico, e il pilastro SD-WAN vero e proprio, che è l’intelligenza di steering.

I casi d’uso da riconoscere

Tre schemi coprono quasi tutti gli scenari che troverai descritti a parole.

Il direct internet access, DIA, è la filiale che esce direttamente su Internet dai propri uplink: policy dalla LAN verso la zona di underlay, destinazione all. Il remote internet access, RIA, è la stessa navigazione fatta uscire dall’hub attraverso l’overlay: destinazione sempre all, ma interfaccia di uscita la zona di overlay. Serve quando il secondo circuito è privato, tipicamente MPLS, e vuoi poterci mandare anche il traffico Internet quando la linea locale cade. Il terzo caso è l’accesso alle risorse di datacenter, che per definizione passa dall’overlay.

Sopra questi si innestano i benefici dichiarati: indipendenza dal trasporto, meno complessità grazie a un unico vendor, e migliore resa delle applicazioni SaaS e cloud, ottenuta indirizzando il traffico per applicazione o per Internet Service.

I quattro oggetti su FortiGate

Il membro è l’interfaccia che porta traffico. Può essere qualunque cosa il FortiGate sappia gestire: porta fisica, VLAN, LAG, tunnel IPsec, GRE, IPIP, interfaccia FortiExtender. Diventare membro non modifica l’interfaccia, ma l’interfaccia deve essere libera da altre configurazioni prima di essere arruolata.

La zona raggruppa i membri, ed è qui che sta il vincolo più citato: un membro non può comparire direttamente in una firewall policy, solo la zona può. Nelle regole SD-WAN, invece, il membro si indica direttamente. Se un’interfaccia richiede un trattamento a sé, la si mette in una zona da sola. La pratica corrente è una zona per l’underlay e una o più per l’overlay.

La performance SLA, o health check, misura la qualità dei membri in termini di latenza, jitter e perdita di pacchetti, in modo attivo o passivo.

La regola SD-WAN, chiamata anche service, dice quale traffico deve seguire quale criterio di scelta. Quando nessuna regola combacia si applica la regola implicita.

La sequenza minima, in CLI

config system sdwan
    set status enable
    config zone
        edit "Underlay"
        next
    end
    config members
        edit 1
            set interface "wan1"
            set zone "Underlay"
        next
        edit 2
            set interface "wan2"
            set zone "Underlay"
            set gateway 10.100.20.2
        next
    end
    config health-check
        edit "server"
            set server "208.91.112.53"
            set update-static-route enable
            set members 1 2
        next
    end
end

Mancano due pezzi, che stanno fuori dal contesto sdwan e sono quelli che si dimenticano. La default route va creata puntando alla zona, non ai singoli gateway dei membri:

config router static
    edit 1
        set sdwan-zone "Underlay"
    next
end

E serve almeno una firewall policy dalla LAN verso la zona, con NAT abilitato se stai facendo DIA. La policy vale per tutti i membri di quella zona: la scelta di quale usare la fanno le regole SD-WAN, non la policy.

Tre trappole di configurazione

Le distanze amministrative non sono uniformi. Un’interfaccia in DHCP che recupera il default gateway dal server installa la propria rotta con distanza 5, mentre una rotta statica ne ha 10 per default: se mescoli DHCP e indirizzamento statico aspettandoti un bilanciamento 50/50, devi portare a 10 la distanza dell’interfaccia DHCP, altrimenti quella rotta vince da sola. Nota che invece una rotta statica che punta a una zona SD-WAN nasce con distanza 1.

Il server dell’health check non è un bersaglio qualsiasi: deve rappresentare la risorsa che ti interessa, perché quello che misuri è la salute del percorso verso quella risorsa, non della linea in assoluto. Puoi indicarne due, e l’health check fallisce solo se falliscono entrambi: un server giù non ti fa dichiarare morto un link sano. Lo stesso server non può però comparire in due performance SLA diverse.

Infine il parametro cost del membro non ha effetto su tutte le strategie: lo usa solo la Lowest Cost (SLA). Impostarlo e poi lasciare la regola in modalità manuale non produce alcun cambiamento.