VRRP LAN/WAN con Connection Tracking synchronization

Sempre più spesso mi viene richiesto di realizzare soluzioni HA (High Availability) impiegando due router con connessione doppia LAN/WAN.

VRRP - Virtual Router Redundancy Protocol

VRRP è il protocollo giusto per questa applicazione

Le interfacce WAN, per esempio, possono comunicare tra loro. In base al valore maggiore di priority, una delle due diventa Master e l'altra Backup. Nel caso il router Backup non raggiunga più il router Master, il router Backup si autoproclama Master. L'interfaccia virtuale VRRP ottiene lo stesso mac-address su entrambi i router e lo stesso IP, garantendo un passaggio immediato al nuovo router.

Il problema principale di questa configurazione è che se la ridondanza è configurata sia su WAN che su LAN, è indispensabile che entrambe siano contemporaneamente o Master o Backup per evitare che un router sia attivo sulla WAN e che l'altro lo sia sulla LAN rendendo impossibile la comunicazione.

Nella versione 7 di RouterOS sono state implementate nuove funzioni di VRRP, tra cui la sincronizzazione delle connessioni presenti nella tabella di Connection Tracking.

Ho pensato fosse utile approfondire questo tema con un laboratorio dedicato.

Su R1 ed R2 configuriamo le interfacce VRRP.

# R1
/interface vrrp
add interface=ether1 name=vrrpWAN priority=200 vrid=1
add interface=ether2 name=vrrpLAN priority=200 vrid=2

# R2
/interface vrrp
add interface=ether1 name=vrrpWAN priority=100 vrid=1
add interface=ether2 name=vrrpLAN priority=100 vrid=2

In questo esempio la WAN è l'ether1 e la LAN è l'ether2. La priorità più alta determina quale router sarà Master, in questo caso R1.

Devono essere ora impostati gli indirizzi IP, ne servono 3 per la WAN e 3 per la LAN. Ogni router ha un indirizzo univoco con relativa subnet mask sulle due interfacce ed uno /32 assegnato all'interfaccia VRRP appena creata. Questo IP sarà attivo solo sul router Master.

# R1
/ip address
add address=172.22.2.221/24 interface=ether1 network=172.22.2.0
add address=172.22.2.220 interface=vrrpWAN network=172.22.2.220
add address=192.168.1.1/24 interface=ether2 network=192.168.1.0
add address=192.168.1.254 interface=vrrpLAN network=192.168.1.254

# R2
/ip address
add address=172.22.2.222/24 interface=ether1 network=172.22.2.0
add address=172.22.2.220 interface=vrrpWAN network=172.22.2.220
add address=192.168.1.2/24 interface=ether2 network=192.168.1.0
add address=192.168.1.254 interface=vrrpLAN network=192.168.1.254

Se non sono disponibili 3 indirizzi IP per ogni interfaccia, è possibile assegnare una subnet /30 dedicata alla comunicazione tra i router e configurare sull'interfaccia VRRP un solo indirizzo appartenente alla subnet che vogliamo usare (es.: 192.168.1.254/24).

Avremo ovviamente bisogno di un default Gateway su entrambi i router.

/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=172.22.2.1

VRRP Script

Se R1 si spegne, R2 diventa Master. Non appena R1 torna attivo acquisisce nuovamente il ruolo di Master. Questo perché il parametro preemtion-mode=yes. Se l'avessimo disabilitato, R2 non avrebbe ceduto il posto ad R1 al suo ritorno.

Se però stacchiamo ad esempio il cavo LAN su R1, solo l'interfaccia LAN su R2 diventa Master, l'altra resta Backup. In questa situazione il sistema smette di funzionare perché i client connessi alla LAN inviano traffico ad R2 ma è ancora R1 il router con la WAN attiva.

Dobbiamo quindi fare in modo che le due interfacce agiscano in sincrono.

Nella versione 7 di RouterOS è presente la possibilità di definire un'interfaccia Group-Master. Tutte le altre VRRP assumono lo stesso ruolo (Master o Backup) della Group-Master.

Noi però vogliamo essere tutelati sia nel caso fallisca la LAN sia nel caso fallisca la WAN. Quindi questa funzione non ci è sufficiente.

A questo scopo ho scritto due script da richiamare nelle interfacce VRRF di R2 (su R1 non servono script). Quando R2 diventa Master in una delle interfacce, esegue lo script vrrpManagerOnMaster, quando diventa Backup esegue lo script vrrpManagerOnBackup.

Modificando il valore di priority delle altre interfacce tutte diventano omogeneamente Master o Backup (lo script funziona anche con più di 2 interfacce VRRP).

# vrrpManagerOnMaster
:global vrrpMaster
:if ([:len [$vrrpMaster]]=0) do={
  :set $vrrpMaster [/interface/vrrp/get [/interface/vrrp/find master=yes] name]
  /interface/vrrp/set [/interface/vrrp/find name!=$vrrpMaster] priority=254
  :log warning "$vrrpMaster is VRRP Master, set other VRRP interfaces priority to 254"
}

# vrrpManagerOnBackup
:global vrrpMaster
:if ([/interface/vrrp/get [/interface/vrrp/find name=$vrrpMaster] master] != yes) do={
  /interface/vrrp/set [/interface/vrrp/find name!=$vrrpMaster] priority=100
  :set $vrrpMaster [:nothing]
  :log warning "All VRRP interfaces are now Backup"
}

Gli script devono avere la policy dont-require-permissions=yes per poter manipolare correttamente le variabili.

Richiamiamo poi gli script dalle interfacce VRRP.

/interface/vrrp/set [find] on-master=vrrpManagerOnMaster on-backup=vrrpManagerOnBackup

Dove metto il DHCP Server?

Per ottimizzare le funzioni del DHCP server l'ideale è configurare R1 ed R2 come DHCP Relay e demandare il ruolo di DHCP server ad un altro router. Nel laboratorio ho configurato una VLAN dedicata per questo servizio ma non è strettamente necessario. Il DHCP server risponde all'indirizzo 10.0.0.3 sulla VLAN10.

# R1 e R2
/ip dhcp-relay
add dhcp-server=10.0.0.3 disabled=no interface=ether2 local-address=192.168.1.254 name=relayLAN

Configuriamo poi il DHCP Server sul router dedicato a questo servizio.

# R3
/ip dhcp-server
add address-pool=poolLAN disabled=no interface=ether1 lease-time=1m name=serverLAN relay=255.255.255.255
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.1.254
/ip pool
add name=poolLAN ranges=192.168.1.100-192.168.1.200

Da notare il parametro relay del DHCP server. Accetta un solo IP. Si più impostare l'IP del DHCP Relay o 255.255.255.255 nel caso ci siano più di un Relay che fanno riferimento allo stesso Server, come nel nostro esempio.

Per navigare serve il NAT ed il NAT vuole il Connection Tracking. Sincronizziamo i due router!

Ora è indispensabile configurare una regola di NAT per consentire ai client connessi alla LAN di navigare in Internet. Uso l'azione src-nat in modo da specificare staticamente l'IP dell'interfaccia VRRP WAN. Se avessi usato masquerade, il router avrebbe usato l'IP presente sull'interfaccia ether1 e non quello virtuale che rimbalza tra un router e l'altro.

# R1 e R2
/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether1 to-addresses=172.22.2.220

Quando interviene VRRP, tutto il traffico passa da un router all'altro. Il router che riceve i flussi dati però non ha assistito alla creazione delle connessioni a cui il traffico appartiene e pertanto non è in grado di procedere con il NAT.

A tale scopo è indispensabile sincronizzare le tabelle di Conection Tracking.

Per aumentare la velocità di sincronia è possibile dedicare un'interfaccia e una subnet a questa funzione, nel nostro esempio ho usato la ether3.

Il connection-tracking deve essere attivo e non su auto come è per impostazione di default.

Nel nostro esempio abilitiamo la sincronia del connection tracking solo sull'interfaccia VRRP LAN, se avessimo bisogno di configurare delle regole di dstnat per traffico proveniente dalla WAN dovremmo abilitarlo anche sulla VRRP WAN.

# R1
/ip address
add address=10.255.255.1/30 interface=ether3 network=10.255.255.0
/ip firewall/connection/tracking/set enabled=yes
/interface/vrrp/set vrrpLAN sync-connection-tracking=yes remote-address=10.255.255.2

# R2
/ip address
add address=10.255.255.2/30 interface=ether3 network=10.255.255.0
/ip firewall/connection/tracking/set enabled=yes
/interface/vrrp/set vrrpLAN sync-connection-tracking=yes remote-address=10.255.255.1

Le connessioni non cadono più!

I router sono configurati. Nel caso uno dei due smetta di funzionare o anche solo un'interfaccia si disconnetta, il traffico passa all'altro router per poi tornare al primo router quando il problema si risolve.

Il DHCP server unico interpellato dai Relay garantisce l'integrità delle leases.

Le tabelle di Connection Tracking sono sincronizzate ed il NAT continua a funzionare senza far scadere le connessioni durante il passaggio tra un router e l'altro.

Missione compiuta!

Accesso al laboratorio

Vuoi connetterti ai router di questo laboratorio e guardare la configurazione?

Invia una mail a info@1off.it.