In questo post vogliamo mostrare una strategia fondamentale ma allo stesso tempo semplice che permette l'incremento della resilienza e dell'affidabilità dei servizi Internet.
Immaginiamo di trovarci nel seguente scenario: abbiamo un cliente e l'azienda di Mario Rossi. Il signor Rossi ha bisogno di un collegamento a Internet per la
propria azienda e desidera che sia il più affidabile possibile. A questo punto potremmo decidere di collegare l'azienda Rossi ad Internet utilizzando due Internet Service Provider (ISP)
differenti, in questo modo se la rete del primo ISP dovesse cadere a causa di una rottura, allora l'azienda Rossi potrà usare la rete del secondo ISP per accedere a Internet.
Una tecnica totalmente automatica che permette il passaggio alla rete del secondo ISP quando il primo ISP è in down, è la tecnica del Failover con Routing Ricorsivo.
Di seguito mostreremo i passaggi da effettuare sui router MikroTik per configurare la WAN di backup.
Innanzitutto configuriamo il router dell'azienda Rossi creando una classica LAN i cui host utilizzeranno l'IP 192.168.1.20/24 come gateway.
Nella LAN di questo esempio:
- è stato assegnato l'IP
192.168.1.200/24al PC1; - è stato configurato l'IP 192.168.1.20/24 sull'interfaccia ether3 del router
utilizzando il comando
ip address add address=192.168.1.20/24 interface=ether3 - è stata applicata una regola di NAT con il comando
ip firewall nat add chain=srcnat action=masquerade src-address=192.168.1.0/24
Figura 1. Per creare la LAN è stata configurata una regola di NAT, l'ip 192.168.1.20/24 sull'interfaccia ether3 del router ed è stato aggiunto l'host PC1.
A questo punto aggiungiamo il collegamento a Internet attraverso il primo ISP, quindi configuriamo l'IP pubblico su un'interfaccia del router del cliente.
In questo caso l'IP "pubblico" è il 10.10.10.1/30 siccome l'esperimento è stato realizzato nell'emulatore GNS3, in un caso reale l'IP sarebbe stato davvero pubblico.
Per configurare l'indirizzo IP basta usare il comando ip address add address=10.10.10.1/30 interface=ether2 come fatto in precedenza.
Figura 2. Si ottiene il primo collegamento a Internet dall'ISP principale, quindi si configura l'IP pubblico sulla ether2.
Lo stesso procedimento si ripete con l'aggiunta del secondo collegamento a Internet, cioè con l'ISP di backup che fornirà un indirizzo pubblico diverso, nello specifico l'IP 20.20.20.1/30.
Figura 3. Si ottiene il secondo collegamento a Internet dall'ISP di backup, quindi si configura un nuovo IP pubblico sulla ether6.
Osserviamo le rotte già presenti nel router dell'azienda Rossi che vengono aggiunte in automatico quando si configura un IP su un interfaccia:
Figura 4. Sulla ether3 è presente l'IP di rete della LAN, sulla ether6 l'IP di rete dell'ISP di backup e sulla ether2 l'IP di rete dell'ISP principale.
Adesso per implementare il failover basta aggiungere quattro semplici rotte.
Innanzitutto aggiungiamo le due rotte che permetteranno successivamente l'aggiunta di rotte il cui gateway non è direttamente collegato al router ma
sarà l'IP di un servizio pubblico in Internet sempre accessibile, ad esempio i server DNS di Google e Cloudflare.
Per aggiungere la prima rotta, in cui usiamo l'IP dei DNS di Google e come
gateway l'IP dell'ISP principale, è possibile usare il comando: ip route add dst-address=8.8.8.8/32 gateway=10.10.10.2 check-gateway=ping.
Per la seconda rotta è possibile usare il comando in cui si indica l'IP dei DNS di Cloudflare e il gateway
dell'ISP di backup: ip route add dst-address=1.1.1.1/32 gateway=20.20.20.2 check-gateway=ping.
Se si preferisce utilizzare winbox bisogna settare i campi come in figura:
Figura 5.A sinistra la rotta che permetterà la creazione di rotte il cui gateway sarà 8.8.8.8 a destra la rotta che permetterà la creazione di rotte il cui gateway sarà 1.1.1.1
A questo punto bisogna aggiungere le rotte che permettono di verificare la raggiungibilità ad Internet attraverso un determintato ISP e allo stesso
tempo fungono da rotte di default.
Infatti come indirizzo di destinazione bisogna specificare 0.0.0.0/0 e come gateway
bisogna specificare 8.8.8.8 o 1.1.1.1.
Nello specifico la prima rotta può essere aggiunta con il comando:
ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 scope=30 target-scope=30
La rotta appena inserita invia un ping ogni 10 secondi all'indirizzo 8.8.8.8, il ping grazie alla rotta a sinistra nella Figura 5 verrà instradato verso l'ISP principale,
in questo modo si verifica se Internet è raggiungibile oppure no attraverso la rete dell'ISP.
Una cosa molto importante da notare è il target-scope della rotta di default che deve essere uguale
allo scope della rotta della Figura 5, in questo modo la rotta di default che ha gateway=8.8.8.8 ha piena visibilità della rotta che ha dst-address=8.8.8.8, in
questo modo è possibile specificare e usare gateway che non sono direttamente collegati al router e che ovviamente NON verrano utilizzati per fare routing del nostro traffico
ma verranno utilizzati soltanto come destinazione del ping per verificare se la rete dell'ISP sta funzionando.
Per aggiungere la seconda rotta: ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1 check-gateway=ping distance=2 scope=30 target-scope=30
La rotta appena inserita invia un ping ogni 10 secondi all'indirizzo 1.1.1.1, il ping grazie alla rotta a destra nella Figura 5 verrà instradato verso l'ISP di backup
in questo modo si verifica se Internet è raggiungibile oppure meno attraverso la rete dell'ISP di backup. Inoltre, siccome questa rotta di default ha una distanza
maggiore della rotta di default precedente viene attivata in automatico solo quando la prima rotta di default diventa inattiva cioè quando non è possibile
pingare il server DNS 8.8.8.8 attraverso l'ISP principale.
Figura 6. A sinistra la rotta di default che resta attiva finchè è possibile pingare l'IP 8.8.8.8 (il ping verrà instradato sull'ISP principale grazie alla regola della figura precedente), se l'ISP principale è in down allora i ping vanno in timeout e la rotta viene disattivata e automaticamente viene attivata la rotta di default a destra.
Riassumendo, oltre alle ultime tre rotte aggiunte automaticamente dal router, si hanno quattro rotte:
Figura 7. La prima rotta di default con gateway 8.8.8.8 che è attiva se il ping verso 8.8.8.8 su rete dell isp principale funziona: se il ping va in timeout la regola viene disattivata automaticamete.
La seconda rotta di default che si attiva solo se la prima viene disattivata, inoltre controlla il funzionamento della rete dell isp di backup inviando dei ping ai dns cloudflare.
La terza rotta permette di instradare i ping verso cloudflare sulla rete dell isp di backup.
La quarta rotta permette di instradare i ping verso google sulla rete dell isp principale.
Testing
Per verificare il corretto funzionamento abbiamo aggiunto un ulteriore router che emula un Internet Exchange Point, a cui abbiamo collegato i due router degli ISP, un host con IP 8.8.8.8, uno con 1.1.1.1 e un ulteriore host chiamato "WEB_SERVER" utilizzato per simulare l'accesso a Internet.
Nella figura seguente possiamo vedere le rotte e il tracert eseguito quando la rete dell'ISP principale funziona correttamente:
In questo caso la prima rotta di default è quella attiva (sigla AS), la seconda evidenziata in blu non è attiva siccome ha distanza maggiore della prima. Nel tracert è possibile osservare l'IP 40.40.40.1 che indica il passaggio del traffico attraverso l'isp principale.
Se invece interrompiamo il link che collega il router dell'ISP principale al routerBGP allora si ha questa situazione:
In questo caso la prima rotta risulta Unreachable, Hw offloaded e Inactive perché non è possbile raggiungere l'IP 8.8.8.8 (quindi Internet) attraverso l'ISP principale e di conseguenza risulta attiva la seconda che permette l'instradamento del traffico attraverso l'ISP di backup, come è possibile osservare nel tracert grazie all'IP 30.30.30.1
Eseguendo il comando ping verso il 2.2.2.2 dall'host della LAN, cioè PC1, avviene questo:
La freccia verde indica i pacchetti verso l'host "WEB_SERVER" quando l'ISP principale funziona correttamente.
La freccia rossa indica i pacchetti persi durante l'aggiornamento delle rotte dovuto al guasto della rete dell'ISP principale e quindi al passaggio automatico sulla rete dell'ISP di backup.
La freccia bianca indica i pacchetti verso l'host "WEB_SERVER" quando è attivo l'ISP di backup e non il principale.