[OpenBSD]

[Precedente: Authpf: User Shell per Gateway di autenticazione] [Indice] [Successivo: Firewall domestico o per piccoli uffici]

PF: Ridondanza di Firewall con CARP e pfsync

Table of Contents

Introduzione a CARP

CARP e' un protocollo Common Address Redundancy. Il suo scopo principale e' di consentire a piu' host sullo stesso segmento di rete di condividere un indirizzo IP. CARP e' un alternativa sicura e gratuita a Virtual Router Redundancy Protocol (VRRP) e a Hot Standby Router Protocol (HSRP).

CARP funziona consentendo a un gruppo di host sullo stesso segmento di rete di condividere un indirizzo IP. Questo gruppo di host e' definito come "gruppo ridondante". Al gruppo ridondante e' assegnato un indirizzo IP condiviso tra i membri del gruppo.Nel gruppo, un host e' il "master" mentre gli altri sono definiti "backups". L' host master e' quello che "detiene" l'indirizzo IP condiviso; risponde direttamente lui a tutto il traffico e a ogni richiesta ARP. Ogni host puo' appartenere contemporaneamente a piu' di un gruppo di redundancy.

Un utilizzo comune di CARP e' di creare un gruppo di firewall ridondanti. L'indirizzo IP virtuale assegnato al gruppo ridondante e' configurato sui client come gateway di default. Se il firewall master avesse dei problemi o venisse spento, l'IP verrebbe trasferito su un firewall di backup senza alcun disservizio.

CARP supporta l' IPv4 e l' IPv6.

Operazioni CARP

L'host master del gruppo invia continui segnali alla rete locale per far si che gli host di backup sappiano del suo corretto funzionamento. Se gli host di backup non dovessero ricevere messaggi dal master per un periodo di tempo prefissato, uno di essi diventera' master occupandosi di tutti i suoi impegni. (l'host backup che ha i piu' valori più bassi di advbase e advskew).

E' possibile che sullo stesso segmento di rete esistano contemporaneamente piu' gruppi CARP. I segnali inviati da CARP contengono l'ID Virtual Host che consente ai membri del gruppo di identificare a quale gruppo ridondante appartiene il messaggio.

Per evitare un uso scorretto del segmento di rete utilizzando messaggi CARP contraffatti, ogni gruppo puo' essere configurato con una password. Ogni pacchetto CARP packet inviato al gruppo e' quindi protetto da un SHA1 HMAC.

Dato che CARP ha un protocollo proprietario, occorre una regola di filtraggio esplicita pass nelle regole di configurazione del filtro:

pass out on $carp_dev proto carp keep state

$carp_dev dovrebbe essere l'interfaccia fisica utilizzata da CARP per comunicare.

Configurare CARP

Ogni gruppo ridondante e' rappresentato da una interfaccia di rete virtuale carp(4). Come tale, CARP viene configurato usando ifconfig(8).
ifconfig carpN create

ifconfig carpN vhid vhid [pass password] [carpdev carpdev] \
   [advbase advbase] [advskew advskew] [state state] ipaddress \
   netmask mask
carpN
Il nome dell'interfaccia virtuale carp(4) dove N e' un intero che rappresenta il numero di interfaccia (es. carp10).
vhid
Il Virtual Host ID. Questo e' un numero unico utilizzato per identificare il gruppo ridondante ad altri nodi sulla rete. Valori accettabili sono da 1 a 255.
password
La password di autenticazione da usare quando si parla ad altri host abilitati CARP in questo gruppo ridondante. Questa deve essere la stessa per tutti i membri del gruppo.
carpdev
Questo parametro opzionale specifica l'interfaccia di rete fisica che appartiene a questo gruppo ridondante. Di default, CARP provera' a determinare quale interfaccia utilizzare cercando tra le interfaccie fisiche nella stessa subnet con la combinazione di ipaddress e mask forniti all'interfaccia carp(4).
advbase
Questo parametro opzionale specifica ogni quanto tempo, in secondi, inviare un messaggio agli altri membri del gruppo ridondante. Di default e' un secondo. Valori accettabili variano tra 1 e 255.
advskew
Questo parametro opzionale specifica di quanto modificare l' advbase quando si inviano i CARP advertisements. Modificando l'advbase, può essere scelto l'host master CARP. Piu' e' alto il numero e meno probabilita' avra' l'host di essere scelto come master. Il valore di default e' 0. Valori accettabili variano tra 0 e 254.
state
Forza un'interfaccia carp(4) in un certo stato. Stati validi sono init, backup, e master.
ipaddress
Questo e' l'indirizzo IP condiviso assegnato al gruppo ridondante. Questo indirizzo non deve essere nella stessa subnet dell'indirizzo IP sull'interfaccia fisica (se presente). Comunque questo indirizzo deve essere lo stesso per tutti gli host del gruppo.
mask
La subnet mask dell'indirizzo IP condiviso.

Il comportamento di CARP puo' essere controllato con sysctl(8).

net.inet.carp.allow
Accetta o no pacchetti CARP in arrivo. Di default è 1 (si').
net.inet.carp.preempt
Permette a host in un gruppo ridondante che hanno un migliore advbase e advskew di appropriarsi del ruolo di master. Inoltre, questa opzione consente di superare eventuali disservizi che potrebbero verificarsi su un'interfaccia. Se un'interfaccia fisica abilitata CARP dovesse smettere di funzionare, CARP modificherà advskew a 240 su tutte le altre interfaccie abilitate CARP. Questa opzione e' 0 (disabilitata) di default.
net.inet.carp.log
Log di pacchetti CARP contraffatti. Default e' 0 (disabilitato).
net.inet.carp.arpbalance
Bilanciamento del carico di traffico su host di piu' gruppi ridondanti. Default e' 0 (disabilitato). Vedere carp(4) per ulteriori informazioni.

Esempio CARP

Un esempio della configurazione di CARP.
# sysctl -w net.inet.carp.allow=1
# ifconfig carp1 create
# ifconfig carp1 vhid 1 pass mekmitasdigoat carpdev em0 \
    advskew 100 10.0.0.1 netmask 255.255.255.0

L'esempio esegue la seguente configurazione:

Per mostrare lo stato dell'interfaccia si può utilizzare ifconfig su carp1.

# ifconfig carp1
carp1: flags=8802<UP,BROADCAST,SIMPLEX,MULTICAST> mtu 1500
     carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
     groups: carp
     inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255

Introduzione a pfsync

L'interfaccia di rete pfsync(4) mostra alcuni cambiamenti eseguiti nella tabella di stato di pf(4). Monitorando questo dispositivo usando tcpdump(8), i cambiamenti della tabella di stato possono essere osservati in tempo reale. Inoltre l'interfaccia pfsync(4) puo' inviare i messaggi relativi a questi cambi di stato fuori sulla rete verso altri nodi sui quali funziona PF per consentire l'aggiornamento delle loro tabelle di stato. Inoltre, pfsync(4) puo' anche ascoltare sulla rete per messaggi in arrivo.

Operare con pfsync

Di default, pfsync(4) non invia o riceve sulla rete update della tabella di stato; comunque, gli update possono essere monitorati usando tcpdump(8) o altri simili tool sulla macchina locale.

Quando pfsync(4) e' configurato per inviare e ricevere update sulla rete, di default invia update multicast sulla rete. Tutti gli update sono inviati senza autenticazione. Pratica comune e':

  1. Connettere i due nodi che si scambieranno gli update usando un cavo crossover e usare quell'interfaccia come syncdev (vedidi seguito).
  2. Usare l'opzione syncpeer ifconfig(8) (vedi di seguito) cosi' che gli update siano unicast diretti al peer, quindi configurare ipsec(4) tra gli host per rendere sicuro il traffico pfsync(4).

Quando gli update sono stati inviati e ricevuti sulla rete, i pacchetti pfsync dovrebbero essere passati nelle regole di configurazione del filtro:

pass on $sync_if proto pfsync

$sync_if dovrebbe essere l'interfaccia fisica con la quale pfsync(4) comunica.

Configurare pfsync

Dato che pfsync(4) e' un'interfaccia di rete virtuale, e' configurata usando ifconfig(8).
ifconfig pfsyncN syncdev syncdev [syncpeer syncpeer]
pfsyncN
Il nome dell'interfaccia pfsync(4). pfsync0 esiste di default quando si utilizza il kernel GENERIC.
syncdev
Il nome dell'interfacca fisica usata per inviare gli update pfsync.
syncpeer
Questo parametro opzionale specifica l'indirizzo IP di un host con il quale scambiare gli update pfsync. Di default gli update pfsync sono multicast per la rete locale. Questa opzione consente la scelta di update unicast allo specifico syncpeer.

Esempio di pfsync

Un esempio di configurazione di pfsync.
# ifconfig pfsync0 syncdev em1
Questo abilita pfsync sull'interfaccia em1. Gli update in uscita saranno multicast inviati sulla rete consentendo ad ogni host con pfsync attivo di riceverli.

Combinazione di CARP e pfsync per i Failover

Associando le caratteristiche di CARP e pfsync, un gruppo di due o piu' firewall possono essere usati per creare un firewall cluster, ridondante e sempre disponibile.
CARP:
Gestisce automaticamente la sostituzione di un firewall danneggiato con un altro.
pfsync:
Sincronizza la tabella di stato tra tutti i firewall. Nel caso in cui si dovesse verificare un failover, il traffico continua a fluire ininterrotto attraverso un nuovo firewall master.

Un esempio di scenario. Due firewall, fw1 e fw2. 

         +----| WAN/Internet |----+ 
         |                        |
      em2|                        |em2   
      +-----+                  +-----+
      | fw1 |-em1----------em1-| fw2 |
      +-----+                  +-----+
      em0|                        |em0
         |                        | 
      ---+-------Shared LAN-------+---

I firewall sono connessi back-to-back usando un cavo crossover su em1. Entrambi sono connessi alla LAN su em0 e alla connessione WAN/Internet su em2. Gli indirizzi IP sono i seguenti:

La policy della rete e' che fw1 sara' il master preferito.

Configurare fw1: 
! abilita il preemption e l'interfaccia di gruppo failover
# sysctl -w net.inet.carp.preempt=1

! configura pfsync
# ifconfig em1 10.10.10.1 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up

! configura CARP su lato LAN
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
     172.16.0.100 netmask 255.255.255.0

! configura CARP su lato WAN/Internet
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
    192.0.2.100 netmask 255.255.255.0

Configurare fw2: 
! abilita la preemption e il failover del gruppo di interfaccia
# sysctl -w net.inet.carp.preempt=1

! configura pfsync
# ifconfig em1 10.10.10.2 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up

! configura CARP su lato LAN
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
     advskew 128 172.16.0.100 netmask 255.255.255.0

! configura CARP su lato WAN/Internet
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
    advskew 128 192.0.2.100 netmask 255.255.255.0

Altre possibili operazioni

Alcune operazioni comuni nell'utilizzo di CARP/pfsync.

Configurare CARP e pfsync durante il Boot

Dato che carp(4) e pfsync(4) sono entrambi tipi di interfaccie di rete, possono essere configurati al boot creando un file hostname.if(5) file. Lo script di startup netstart si prendera' cura di creare l'interfaccia e configurarla.

Esempi:

/etc/hostname.carp1
inet 172.16.0.100 255.255.255.0 172.16.0.255 vhid 1 carpdev em0 \
    pass lanpasswd

/etc/hostname.pfsync0
up syncdev em1

Forzare il failover del Master

A volte può essere necessario provocare il failover del nodo master. Per esempio si può escludere il nodo master per manutenzione o per problemi. L'obiettivo è di far passare il traffico ad uno degli host di backup senza che gli utenti si accorgano del cambio.

Per il failover di un particolare gruppo CARP, disattivare l'interfaccia carp(4) sul nodo master. Il master inizierà a inviare messaggi con un advbase e advskew "infinito". Tra gli host di backup vi sarà un nuovo master.

# ifconfig carp1 down

Un'alternativa è di incrementare advskew a un valore più alto dell'advskew sugli host backup. Questo causa un failover del master che comunque continua a partecipare al grupppo CARP.

Un altro metodo per il failover è di allineare il contatore demotion. Il contatore demotion è una misura di quanto "pronto" sia un host a divenire master di un gruppo CARP. Per esempio, mentre un host sta facendo il boot è una cattiva idea farlo divenire master CARP fin quando non siano state configurate tutte le interfaccie, avviati tutti i servizi, ecc. Host che comunicano un valore elevato di demotion saranno i meno preferiti nel divenire master.

Un contatore demotion è conservato in ogni gruppo di interfaccie appartenenti a CARP. Per default, tutte le interfaccie CARP sono membri del gruppo "CARP" di interfaccie. Il valore corrente di un contatore demotion può essere visto usando ifconfig(8):

# ifconfig -g carp
carp: carp demote count 0

In questo esempio viene mostrato il contatore associato al gruppo interfaccia "carp". Quando un host CARP comunica se stesso sulla rete, esso prende la somma dei contatori demotion per ogni gruppo interfaccia alla quale l'interfaccia carp(4) appartiene e comunica questo valore come suo valore di demotion.

Consideriamo il seguente esempio: Due firewall con CARP con le seguenti interfaccie CARP:

L'obiettivo è di avere un failover dei gruppi carp1 e carp2 al secondo firewall.

Per prima cosa assegnamo ognuno ad un nuovo gruppo di interfaccia chiamata "internal":

# ifconfig carp1 group internal
# ifconfig carp2 group internal
# ifconfig internal
carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
     carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 100
     groups: carp internal
     inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
carp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
     carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 100
     groups: carp internal
     inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255

Ora incrementiamo il contatore demotion per il gruppo "internal" usando ifconfig(8):

# ifconfig -g internal
internal: carp demote count 0
# ifconfig -g internal carpdemote 50
# ifconfig -g internal
internal: carp demote count 50

Ora il firewall effettuerà un failover sui gruppi carp1 e carp2 per l'altro firewall del cluster, mentre continua ad essere master per i gruppi carp3 e carp4. Se l'altro firewall dovesse iniziare a promuovere se stesso con un valore di demotion più alto di 50, oppure se l'altro firewall smettesse a un tratto di inviare messaggi, questo firewall riprenderebbe ad essere master per carp1 e carp2.

Per tornare al firewall primario occorre invertire i comandi:

# ifconfig -g internal -carpdemote 50
# ifconfig -g internal
internal: carp demote count 0

Servizi di rete come OpenBGPD e sasyncd(8) usano il demotion counter per assicurarsi che il firewall non diventi master finchè non si sia stabilita la sessione BGP e sia sincronizzato l'IPsec.

Suggerimenti di regole di configurazione

Filtrare l'interfaccia fisica. Il traffico di rete avviene sulle interfaccie fisiche e non su qquelle virtuali CARP(es: carp0). Quindi le regole dovranno essere opportune. Occorre ricordare che un nome di interfaccia in una regola PF può essere sia il nome di un'interfaccia fisica oppure un indirizzo associato a quella interfaccia. Per esempio questa regola potrebbe essere corretta:
pass in on fxp0 inet proto tcp from any to carp0 port 22
ma sostituendo fxp0 con carp0 non funziona come desiderato.

NON dimenticare di far passare proto carp e proto pfsync!

Altri riferimenti

Per ulteriori informazioni fare riferimento a:

[Precedente: Authpf: User Shell per Authenticating Gateway] [Indice] [successivo: Firewall domestico o per piccoli uffici]

[back] www@openbsd.org
$OpenBSD: carp.html,v 1.2 2008/04/15 11:07:13 tobias Exp $