Secure SD-WAN: test e considerazioni relativi alla topologia enterprise

Secure SD-WAN: test e considerazioni relativi alla topologia enterprise

I seguenti test sono stati effettuati sulla base della topologia SD-WAN enterprise costruita e configurata nel precedente articolo.

Traffico Internet – Fail di un link

Come primo test simuliamo il fail di un link e vediamo come si comporta il traffico verso Internet. Da un Virtual PC collegato in LAN del Branch1 lanciamo un ping continuo verso l’ip del DNS Google 8.8.4.4:

SDwan_Test_ConsiderazioniÈ possibile constatare nella sezione relativa alle SD-WAN Rules che l’interfaccia di uscita selezionata è Port1 per via delle migliori performance misurate rispetto a Port2:

SDwan_Test_Considerazioni1

Impostando uno sniffer sul firewall possiamo vedere nel dettaglio i pacchetti icmp echo request diretti all’host 8.8.4.4 che arrivano in ingresso sulla port3 e, una volta processati, vengono fatti uscire dalla port1 con nat di sorgente sull’ip 100.10.10.1. Le risposte naturalmente seguono il path inverso: i pacchetti icmp echo reply entrano da port1 e vengono inviati dalla port3 all’host 172.16.10.1

SDwan_Test_Considerazioni_2

A questo punto simuliamo il fail della connettività spegnendo il router collegato alla port1. Dal VPC in LAN del Branch1 stiamo continuando a pingare l’ip 8.8.4.4, non appena viene spento il router due richieste icmp vanno in timeout e subito dopo ritorna a pingare.

SDwan_Test_Considerazioni_3

Quando si verifica l’interruzione di connettività i performance sla la rilevano e dichiarano la port1 e le interfacce vpn annesse come “dead” mentre le altre interfacce rimangono in stato “alive”.

SDwan_Test_Considerazioni_4

La tabella di routing viene dunque aggiornata rimuovendo le interfacce in stato “dead”.

SDwan_Test_Considerazioni_6

Nella sezione relativa alle SD-WAN rules possiamo vedere che ora l’interfaccia designata per il traffico internet è port2:

Per controprova lo sniffer impostato sul firewall mostra i pacchetti icmp echo request diretti all’host 8.8.4.4 che arrivano in ingresso sulla port3 e vengono fatti uscire dalla port2 con nat di sorgente sull’ip 200.10.10.1. Le risposte seguono il path inverso: i pacchetti icmp echo reply entrano da port2 e vengono inviati dalla port3 all’host 172.16.10.1.

SDwan_Test_Considerazioni_8Ripristinando il router connesso alla port1 dopo un breve periodo di tempo il traffico torna ad essere rediretto verso tale interfaccia di uscita senza nessuna perdita di pacchetti.

SDwan_Test_Considerazioni_9

SDwan_Test_Considerazioni_10

Traffico verso HUB – Interface Preference

Come secondo test andiamo a modificare la rule SD-WAN per il traffico diretto al DC, impostando che venga utilizzato preferenzialmente il link attestato sulla port2 e dunque la VPN “WAN2-DC”. Attualmente la rule specifica è configurata con criterio latency e l’intefaccia scelta è “WAN1-DC”.

SDwan_Test_Considerazioni_11

Se dal VPC in LAN sul Branch1 proviamo a pingare l’ip dell’interfaccia LAN del FortiGate DC vediamo come il traffico venga instradato attraverso quest’ultimo tunnel VPN.

SDwan_Test_Considerazioni12

A questo punto editiamo il Performance SLA “pingDC” definito in precedenza ed andiamo ad impostare uno SLA target:

SDwan_Test_Considerazioni_13

Andando in edit sulla SD-WAN rule ora modifichiamo la strategia in Lowest Cost (SLA) e modifichiamo l’ordine delle interfacce inserendo come preferenziale WAN2-DC. Come SLA target selezioniamo “PingDC”.

SDwan_Test_Considerazioni_14

A questo punto i pacchetti che prima venivano instradati attraverso il tunnel VPN “WAN1-DC” cominciano ad essere inviati al DC attraverso il nuovo tunnel preferenziale:

SDwan_Test_Considerazioni_15

Dallo Sniffer si può vedere esattamente il cambio di instradamento che per l’utente (in questo caso il VPC) risulta del tutto trasparente.

SDwan_Test_Considerazioni_16

A questo punto se si verifica un fail della connettività attestata sulla port2 notiamo come senza nessuna perdita di pacchetti il traffico sia rediretto sull’altro tunnel:

SDwan_Test_Considerazioni_17

SDwan_Test_Considerazioni_18

Traffico Branch 2 Branch – Ridondanza e Business Continuity

Come terzo Test verifichiamo la comunicazione tra Branch la quale avviene attraverso i due HUB. Nello specifico la rule SD-WAN che permette questo traffico utilizza il link con minor latenza che attualmente è WAN1-HQ per via delle migliori performance.

SDwan_Test_Considerazioni_19

Cosa succederebbe se HQ avesse un disservizio infrastrutturale tale da determinare la non raggiungibilità del Firewall? Per provarlo spegniamo l’appliance HQ lasciando un ping continuo verso il Branch2 172.16.20.254:

SDwan_Test_Considerazioni_20

Possiamo notare che vengono persi due pacchetti dovuti all’aggiornamento delle tabelle arp dei dispositivi, dopodiché il traffico torna a fluire senza problemi. Dallo sniffer sul Fortigate Branch1 possiamo apprezzare il cambio di interfaccia di uscita per le richieste icmp (da WAN1-HQ a WAN1-DC).

SDwan_Test_Considerazioni_21

Nella SD-WAN rule possiamo poi notare che l’interfaccia selezionata ora è proprio WAN1-DC.

SDwan_Test_Considerazioni_22

Vuoi saperne di più?
Lasciaci i tuoi contatti, verrai ricontattato da uno dei nostri specialisti.

    Inviando il modulo, accetti di essere contattato per i prodotti e servizi Nethive.