Failover su Mikrotik ROS 7.x

Questa è la configurazione più semplice in assoluto. Prevede di avere due provider, uno principale che è sempre usato a meno che non abbia un guasto, e uno secondario che non è mai usato a meno che il principale non muoia. In questo esempio il principale è una FTTH e il secondario è una connessione 4G, ma non fa nessuna differenza se usate due VDSL o due FTTH o quello che volete.

Questa configurazione permette al traffico entrante da entrambe le connessioni di essere ridiretto (DNAT) verso delle macchine interne, o di essere ricevuto dal nostro Mikrotik. Per fare questo occorre che esista una regola che dice, in sostanza: "se il traffico entra dal provider secondario, i pacchetti che escono come risposta devono anche essi passare per il provider secondario, anche se il primario è online"

La configurazione in questo esempio prevede di avere due router per i nostri due provider, tutti e due con una subnet privata dietro al router, e tutti gli ip assegnati al Mikrotik sono statici, e le rotte inserite manualmente. Essendo una configurazione "asimmetrica", cioè una configurazione nella quale un provider è sempre attivo e l'altro è solo una scorta, la posso semplificare molto rispetto alla configurazione con load balancing.

Funzionalità che vogliamo ottenere

Tutto il traffico passa sul provider principale (FTTH), niente passa sul secondario (4G), a meno che il master non si guasti
Le connessioni da fuori a dentro funzionano sempre su tutti e due i provider, in altri termini anche quanto FTTH funziona il traffico entrante dal 4G viene gestito correttamente
Uso un ping verso un ip esterno (9.9.9.9 o altro ip pubblico che so essere raggiungibile con un ping) per determinare se la FTTH sta funzionando o no

Descrizione dettagliata della configurazione del sistema

Per aiutarvi a capire come funziona il sistema, descrivo qui la configurazione usata in questo esempio.

ether1 è la interfaccia connessa al router FTTH (principale) con ip 192.168.1.0/24, dove il router del provider è il .1 e il Mikrotik è il .2, tutto statico, niente dhcp.
ether2 è la interfaccia connessa al router 4G (secondario) con ip 192.168.2.0/24, dove il router del provider è il .1 e il Mikrotik è il .2, tutto statico, niente dhcp.
ether1 e ether2 sono state messe tutte e due nella interface list denominata "WAN"
usiamo 9.9.9.9 (un DNS pubblico che risponde al ping) come indirizzo da pingare per vedere se la FTTH è online o è rotta
Le regole di firewall "minime" sono già presenti (in pratica, la default config) per cui non mi occuperò né della sicurezza né della configurazione del SNAT fra LAN e WAN

Configurazione

Passiamo quindi alla effettiva configurazione del Mikrotik:

Creare una routing table per il provider secondario. (siccome questa configurazione e` "asimmetrica", prevede un provider principale e uno secondario senza load balancing, non mi servono due routing table una per ogni provider. Il provider principale userà la routing table "main")
```
/routing table
add disabled=no fib name=4G_table
```
Nella routing table cosi` creata, imposto una rotta per default (0.0.0.0/0) verso il router del provider secondario. Essendo questo il provider di backup, e volendo io evitare di fare traffico inutile (qui sono limitato, e` una connessione 4G) non abilito alcun check per vedere se il provider e` up, do per scontato che lo sia. Questa regola di routing verrà usata dal traffico che verrà marcato dalle regole di mangle che dovremo inserire nel firewall (sezione "mangle") in seguito. Il traffico non marcato continuerà a usare la table "main".
```
/ip/route
add routing-table=4G_table dst-address=0.0.0.0/0 gateway=192.168.2.1
```
Nella routing table "main" devo ora inserire due rotte, una verso il provider principale con distanza minore e con attiva la funzione di check-gateway, e una verso il secondario con distanza maggiore e senza check-gateway (come abbiamo detto prima, io do per scontato che il secondario sia attivo e non voglio fare traffico inutile su di esso). E` importante inserire qui nella main la rotta per il provider secondario con una distanza maggiore rispetto a quella del primario, in questo modo la rotta del secondario sara` DISATTIVA fintanto che il primario è funzionante. Questa configurazione farà si che il traffico giri sempre e solo per il provider principale fino a che questo funziona. Quando il principale muore, il traffico passerà solo per il secondario. In questo specifico caso, dove il provider principale non usa PPPoE, e` inutile che io usi la funzione "check-gateway=ping" perché pingherei il router del provider che si trova a fianco del mio Mikrotik. Per questo motivo devo basare il controllo di connettività su un ping a un indirizzo che sia su internet, come per esempio 9.9.9.9 o 8.8.8.8; per farlo devo usare il trucco del routing ricorsivo, complicandomi un poco la vita.
```
# rotta per il provider principale con check di connettività con ping a 9.9.9.9
/ip/route
add disabled=no distance=1 dst-address=9.9.9.9/32 gateway=192.168.1.1 routing-table=main scope=11 target-scope=10
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=9.9.9.9 routing-table=main scope=30 target-scope=11

# rotta per il provider secondario senza check di connettività (notare la distance=2 che la rende inattiva fintanto che quella precedente, con distance=1, è attiva)
/ip/route
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.2.1 routing-table=main distance=2
```

Nella sezione "mangle" del firewall, devo definire delle regole che permettano al traffico entrante dal provider secondario di essere rimandato indietro attraverso lo stesso provider secondario, anche se il primario è online. Creo quindi una regola dice che le connessioni in connection state "new" che entrano dalla interfaccia connessa al provider secondario e che hanno attualmente nessun connection mark devono essere marcate con un connection mark "mark_4G" (nome arbitrario che userò in seguito per routare il traffico di risposta). Se non facessi questo, i pacchetti di risposta per l'eventuale traffico entrante dall'esterno attraverso il provider secondario verrebbero fatti uscire tramite il provider primario, e queste connessioni entranti di conseguenza non funzionerebbero, almeno fino a che il primario è online. Per il traffico entrante ho due scenari possibili: in un caso il traffico è diretto al Mikrotik stesso, nell'altro caso viene ridiretto (DNAT) vero macchine in LAN (o in DMZ, se l'avete). Devo creare regole per gestire tutti e due i casi.

# metto un connection mark al traffico entrante dal secondario (ether2) se non ha già un mark
/ip/firewall/mangle 
add action=mark-connection chain=prerouting connection-mark=no-mark connection-state=new in-interface=ether2 new-connection-mark=4G_conn passthrough=yes            

# il traffico in uscita dal Mikrotik che ha il connection mark va mandato alla routing table "4G_table" (vedi punto 1 e 2)
/ip/firewall/mangle 
add action=mark-routing chain=output connection-mark=4G_conn new-routing-mark=4G_table passthrough=yes

# il traffico in uscita dalla LAN verso internet che ha il connection mark va mandato alla routing table "4G_table" (vedi punto 1 e 2)
/ip/firewall/mangle 
add action=mark-routing chain=prerouting connection-mark=4G_conn in-interface-list=LAN new-routing-mark=4G_table passthrough=yes        

# il traffico in uscita dalla DMZ verso internet che ha il connection mark va mandato alla routing table "4G_table" (vedi punto 1 e 2)
/ip/firewall/mangle 
add action=mark-routing chain=prerouting connection-mark=4G_conn in-interface-list=DMZ new-routing-mark=4G_table passthrough=yes

Test

Ora che la configurazione è fatta possiamo provarla.

Con tutti e due i provider connessi, il traffico generato dalla LAN deve uscire sempre tutto verso il provider principale.
Con tutti e due i provider connessi, il traffico entrante dal provider principale deve funzionare, sia esso diretto verso il Mikrotik o sia esso ridiretto da una regola di DNAT verso la rete interna
Con tutti e due i provider connessi, il traffico entrante dal provider secondario deve funzionare, sia esso diretto verso il Mikrotik o sia esso ridiretto da una regola di DNAT verso la rete interna
Disconnettendo il provider principale, dopo una decina di secondi al massimo deve avvenire la commutazione, e il traffico generato dalla LAN deve uscire sempre tutto verso il provider secondario.
Con il provider principale disconnesso, ovviamente il traffico entrante dal provider principale non funzionerà, però deve rimanere funzionante il traffico entrante dal provider secondario.
Riconnettendo il provider principale, dopo una decina di secondi al massimo deve avvenire la commutazione, e il traffico generato dalla LAN deve uscire sempre tutto verso il provider principale.

Configurazione con PPPoE

Se il nostro provider principale usa PPPoE, possiamo semplificare moltissimo il punto 3, dove non ci serve più il controllo della connettività in quanto quasi sicuramente in caso di guasto cadrà il pppoe e questo causerà la sparizione della rotta per il provider principale, di fatto quindi dovremo solo inserire la rotta per il secondario e niente altro. Il resto non cambia.