In quest’articolo andremo a vedere passo dopo passo gli aspetti configurativi dell’ultimo caso d’uso SD-WAN enterprise analizzato nell’articolo precedente dove vengono utilizzate connettività Internet ridondate e la comunicazione tra i vari Branch avviene tramite un overlay VPN.
Per farlo abbiamo simulato in un ambiente virtuale una topologia enterprise multisede che comprende 4 Branch, un Head Quarter e un Data Center. Ogni Branch è dotato di due connettività Internet così come anche il Data Center e l’HQ. La topologia utilizzata in questo caso è Dual-HUB & SPOKE in quanto i Branch avranno dei link VPN verso l’HQ e il Data Center ma non direttamente tra di loro, dunque il traffico dati di comunicazione tra i Branch avverrà sempre attraverso uno dei due HUB.
Questa topologia consente di avere la ridondanza necessaria a garantire continuità di servizio in caso di fail o congestione di uno dei due link dei Branch. Inoltre, in caso di un disservizio totale di uno dei due HUB è garantita comunque la comunicazione tra i vari Branch e il raggiungimento dei servizi situati sull’HUB rimasto attivo. Implementando opzionalmente poi una strategia di Disaster Recovery è possibile garantire Business Continuity anche in caso di disastro. In questa simulazione sono stati configurati dei tunnel VPN ipsec statici. Un’altra soluzione è quella di utilizzare la tecnologia ADVPN per instaurare degli shortcut dinamici tra gli spoke e protocolli di routing dinamico per annunciare le network locali ai neighbors ma rimandiamo tale simulazione ad altro approfondimento.
La versione firmware utilizzata nel POC è FortiOS 6.4.0 che introduce importanti novità riguardanti l’SD-WAN: https://docs.fortinet.com/document/fortigate/6.4.0/new-features/830751/sd-wan. Una volta configurati i parametri base di network dei vari host passiamo ad implementare la configurazione SD-WAN.
Sequenza configurativa di un HUB
1. VPN
É necessario creare un tunnel VPN verso ogni Branch per entrambe le interfacce WAN.
2. Static Routes
É sufficiente configurare una singola rotta di Default via SD-WAN.
3. Overlay
Alle interfacce VPN deve essere assegnato un IP in una network di overlay punto-punto. In questo caso sono state scelte delle network /24 anche se è sufficiente una/30. Questo passaggio è indispensabile per designare i source IP degli health check SD-WAN (performance SLA) avendo l’obbiettivo di includere anche le interfacce VPN nel virtual-wan-link.
4. SD-WAN Interface
Dalla sezione SD-WAN si devono aggiungere tutte le interfacce VPN e le due WAN (port1 e port2) alla virtual interface assegnando i corretti gateway.
5. Performance SLA
A questo punto si devono configurare gli health check o performance SLA. Per ogni branch vanno configurati uno o più ping server, in questo caso utilizziamo l’interfaccia inside dei firewall remoti ma potrebbero essere anche delle loopback oppure possono essere utilizzati degli host in lan. É essenziale che i server scelti rispondano sempre ai probe packets, un fail del server determinerebbe il superamento delle soglie di Performance SLA con conseguente trig dell’eliminazione delle rotte dalla FIB. Per questo motivo è best practice configurare più di un Detect Server in un ambiente di produzione. Sono disponibili più protocolli per una maggior definizione dei probe packets in base alle esigenze ma generalmente il ping va benissimo per lo scopo.
Per ogni branch andremo a configurare dunque il server, il protocollo e le interfacce partecipanti, inserendo i tunnel VPN che terminano verso il relativo Firewall remoto. Andiamo inoltre ad inserire uno SLA target (in questo caso 25ms Latency Threshold, 10 ms Jitter threshold e 2% Packet loss Threshold). Per gli altri parametri lasciamo i valori di default.
6. SD-WAN Rules
Le SD-WAN Rules sostanzialmente sono delle regole di routing che si avvalgono degli healthcheck definiti pocanzi. Esiste una regola implicita che bilancia di default il traffico in base al source ip, questa può essere editata per modificare l’algoritmo di bilanciamento con la possibilità di configurare pesi o threshold per andare a fare del fine tuning.
Le SD-WAN Rules agiscono come il Policy Based Routing entrando in gioco prima della tabella di routing e sono processate top-down, il che significa che un pacchetto in ingresso verrà instradato in base alla prima SD-WAN rule con cui farà match e tutte le altre saranno ignorate, se non ci sarà un match con nessuna regola definita, verrà processato utilizzando la rule implicita. Per la nostra simulazione configuriamo le rules verso ogni branch utilizzando semplicemente network sorgente e di destinazione ma è possibile definire la regola specificando altri parametri. Potremmo utilizzare l’applicazione o l’internet service come destinazione mentre come sorgente possiamo andare ad aggiungere degli utenti radius, tacacs+, ldap, o locali per avere un maggior controllo. Nella parte relativa alle strategie troviamo:
- Manual – Permette di forzare l’instradamento su un’interfaccia senza dipendere da performance SLA o SLA target.
- Best Quality – Questo criterio è basato sulla performance dei link, verrà utilizzato il primo link inserito (in questo caso Branch1-WAN1) fintanto che la sua latenza/jitter/packet loss sarà fino al 10% peggiore del secondo link, a quel punto prenderà posto quest’ultimo. La soglia del 10% è un valore di default ma configurabile da CLI.
- Lowest Cost (SLA) – Con questo criterio l’outgoing interface viene determinata, tra le partecipanti, in base a una serie di fattori: in primis viene preso in considerazione uno SLA target definito nei Performance SLA. Le interfacce che non rispettano tale SLA target vengono scartate, come secondo step viene preso in carico il costo, che di default è 0 ma è un valore configurabile. Verrà preferita l’interfaccia col costo più basso tra quelle che rispettano lo sla target; il terzo fattore è la preferenza: a parità di costo “vincerà” l’interfaccia con preferenza più alta, ossia quella che viene prima in ordine di inserimento.
- Maximize Bandwidth (SLA) – Questo criterio permette di bilanciare le sessioni con metodo round robin tra i link che rispettano un dato SLA target, in questo caso non vengono considerati costo e preferenza.
Per la nostra simulazione utilizziamo la strategia Best Quality con Latency come Quality Criteria:
7. Firewall Policy
Definiamo le firewall policies andando a consentire il traffico da e verso il DC e tra i branch. Servono complessivamente 4 regole:
- da Port3 a SD-WAN per il traffico dal DC verso i Branch;
- da SD-WAN a Port3 per il traffico dai Branch verso il DC;
- da SD-WAN a SD-WAN per il traffico da Branch a Branch;
- da Port3 a SD-WAN con SNAT sull’indirizzo dell’interfaccia di uscita per la navigazione internet. L’interfaccia di uscita potrà essere sia port1 che port2 in base alla latenza come definito nella relativa SD-WAN rule.
Sequenza di configurazione dello spoke
1. VPN
Su ogni branch andiamo a creare 4 tunnel VPN ipsec: per ogni interfaccia WAN un tunnel VPN verso il DC e uno verso l’HQ.
2. Static Routes
É sufficiente configurare una singola rotta di Default via SD-WAN:
3. Overlay
Come negli HUB andiamo a configurare gli ip nelle network punto-punto di overlay VPN:
4. SD-WAN Interface
Nel modulo relativo all’SD-WAN si devono aggiungere tutte le interfacce VPN e le due WAN (port1 e port2) alla virtual interface assegnando i corretti gateway:
5. Performance SLA
Configuriamo tre Performance SLA. Il primo avrà come Detect Server un server pubblico (ad es: DNS Google 8.8.8.8) e servirà per misurare latenza, jitter e packet loss delle due WAN; gli altri due avranno come Detect Server gli ip dell’interfaccia inside dei due HUB, ma come detto in precedenza potrebbero essere dei server in LAN o delle loopback interface. É essenziale che i server scelti rispondano sempre ai probe packets, un fail del server determinerebbe il superamento delle soglie di Performance SLA con conseguente trig dell’eliminazione delle rotte dalla FIB. Per questo motivo è best practice configurare più di un Detect Server in un ambiente di produzione.
6. SD-WAN Rules
Andiamo a definire quattro SD-WAN Rules: una per il traffico verso il DC, una per il traffico verso l’HQ, una per quello verso i branch e una per il traffico Internet. Anche in questo caso configuriamo su tutte le rules il Criteria “Latency”:
Come si può vedere dall’immagine una comoda novità di FortiOS 6.4 è data dal flag che indica l’interfaccia effettivamente in uso dalla rule, in questo caso in base alla latenza.
7. Firewall Policy
Come ultimo step configurativo andiamo a definire tre Firewall policy su ogni Branch.
- Da SD-WAN a Port3 per il traffico che arriva dai branch remoti e dai due HUB
- Da Port3 a SD-WAN per il traffico verso i due HUB e i Branch remoti
- Da Port3 a SD-WAN per la navigazione internet con SNAT sull’indirizzo dell’interfaccia di uscita. L’interfaccia di uscita potrà essere sia port1 che port2 in base alla latenza come definito nella relativa SD-WAN rule.
Nel prossimo articolo eseguiremo dei test pratici di failover e di verifica delle funzionalità dell’SD-WAN sulla base delle configurazioni implementate e descritte in precedenza.
