[Anterior: Shell de Usuário para Gateways de Autenticação] [Conteúdo] [Próximo: Firewall para Casa ou Pequeno Escritório]
CARP funciona permitindo a um grupo de máquinas no mesmo segmento de rede compartilhar um endereço IP. Esse grupo de máquinas é referido como um "grupo de redundância". Ao grupo de redundância é atribuído um endereço IP que é compartilhado entre os membros do grupo. Dentro do grupo, uma máquina é designada como "mestre" e o resto como "backups". A máquina mestre é a que atualmente "segura" o IP compartilhado; ela responde a qualquer tráfego ou requisições ARP direcionadas a ele. Cada máquina pode pertencer a mais de um grupo de redundância por vez.
Um uso comum para o CARP é criar um grupo de firewalls redundantes. O IP virtual que é atribuído ao grupo de redundância é configurado nas máquinas clientes como o gateway padrão. Caso o firewall mestre sofra uma falha ou seja desligado, o IP se moverá para um dos firewalls backup e o serviço vai continuar sem ser afetado.
É possível que múltiplos grupos CARP existam no mesmo segmento de rede. Anúncios CARP contêm o ID de Máquina Virtual (VHID - "Virtual Host ID") que permite aos membros do grupo identificar a que grupo de redundância pertencem.
Para prevenir que um usuário malicioso no segmento de rede falsifique anúncios CARP, cada grupo pode ser configurado com uma senha. Cada pacote CARP enviado ao grupo é então protegido por um HMAC SHA1.
Como o CARP é seu próprio protocolo, ele deve ter uma regra de permissão explícita no conjunto de regras de filtragem:
pass out on $carp_dev proto carp keep state
$carp_dev deve ser a interface física por onde o CARP se comunica.
ifconfig carpN create
ifconfig carpN vhid vhid [pass senha] [carpdev carpdev] \
[advbase advbase] [advskew advskew] [state estado] endereço_ip \
netmask máscara
Além disso, o comportamento do CARP pode ser controlado via sysctl(8).
# 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
Isso configura o seguinte:
Executar o ifconfig na carp1 mostra o status da interface.
# 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
Quando o pfsync(4) está configurado para enviar e receber atualizações na rede, o comportamento padrão é enviar atualizações "multicast" na rede local. Todas as atualizações são enviadas sem autenticação. A prática mais comum é:
Quando as atualizações estão sendo enviadas e recebidas na rede, os pacotes pfsync devem ser aceitos no conjunto de regras de filtragem.
pass on $sync_if proto pfsync
$sync_if deve ser a interface física por onde o pfsync(4) se comunica.
ifconfig pfsyncN syncdev syncdev [syncpeer syncpeer]
# ifconfig pfsync0 syncdev em1Isso habilita o pfsync na interface em1. As atualizações enviadas serão "multicast" na rede, permitindo que qualquer outra máquina executando o pfsync possa recebê-las.
Um cenário de exemplo. Dois firewalls, fw1 e fw2.
+----| WAN/Internet |----+
| |
em2| |em2
+-----+ +-----+
| fw1 |-em1----------em1-| fw2 |
+-----+ +-----+
em0| |em0
| |
---+----LAN Compartilhada---+---
Os firewalls estão conectados diretamente com um cabo cruzado em em1. Ambos estão conectados à LAN em em0 e a uma conexão WAN/Internet em em2. Os endereços IP são os seguintes:
A política de rede é que fw1 será o mestre preferido.
Configuração do fw1:
! Habilita a função de tomar o lugar e o failover de interface de grupo
# sysctl -w net.inet.carp.preempt=1
! Configura o pfsync
# ifconfig em1 10.10.10.1 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! Configura o CARP no lado LAN
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
172.16.0.100 netmask 255.255.255.0
! Configura o CARP no lado WAN/Internet
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
192.0.2.100 netmask 255.255.255.0
|
Configuração do fw2:
! Habilita a função de tomar o lugar e o failover de interface de grupo
# sysctl -w net.inet.carp.preempt=1
! Configura o pfsync
# ifconfig em1 10.10.10.2 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! Configura o CARP no lado LAN
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
advskew 128 172.16.0.100 netmask 255.255.255.0
! Configura o CARP no lado WAN/Internet
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
advskew 128 192.0.2.100 netmask 255.255.255.0
|
Exemplos:
Para failover de um grupo CARP em particular, derrube a interface carp(4) no nó mestre. Isso faz com que o mestre anuncie a si mesmo com um advbase e advskew "infinito". A(s) máquina(s) backup vê(eem) isso e imediatamente toma(m) o lugar da máquina mestre.
# ifconfig carp1 down
Uma alternativa é aumentar o advskew para um valor mais alto que o advskew na(s) máquina(s) backup. Isso causa um failover, mas ainda permite ao mestre participar no grupo CARP.
Um outro método para failover é ajustar o contador demotion do CARP. O contador demotion é uma medida de como "pronta" uma máquina está para se tornar o mestre do grupo CARP. Por exemplo, enquanto uma máquina está no meio do processo de inicialização é uma má ideia para ela tornar-se um mestre CARP até que todas as interfaces estejam configuradas, todos os serviços de rede estejam iniciados, etc. Máquinas anunciando um valor demotion alto terão menos preferência como mestre.
Um contador demotion é armazenado em cada grupo de interfaces que a interface CARP pertence. Por padrão, todas as interfaces CARP são membros do grupo de interfaces "carp". O valor atual de um contador demotion pode ser visto usando o ifconfig(8):
# ifconfig -g carp
carp: carp demote count 0
Nesse exemplo o contador associado com o grupo de interface "carp" é mostrado. Quando uma máquina CARP anuncia a si mesma na rede, ela pega a soma dos contadores demotion para cada grupo de interfaces que a interface carp(4) pertence e anuncia esse valor como seu valor demotion.
Agora assuma o seguinte exemplo. Dois firewalls executando CARP com as seguintes interfaces CARP:
O objetivo é apenas fazer failover dos grupos carp1 e carp2 para o firewall secundário.
Primeiro, associe cada grupo a um novo grupo de interfaces, neste caso nomeado como "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
Agora aumente o contador demotion para o grupo "internal" usando o ifconfig(8):
# ifconfig -g internal
internal: carp demote count 0
# ifconfig -g internal carpdemote 50
# ifconfig -g internal
internal: carp demote count 50
O firewall agora faz elegantemente o failover nos grupos carp1 e carp2 para o outro firewall no cluster, enquanto ainda se mantém como mestre nos grupos carp3 e carp4. Se o outro firewall começar a anunciar um valor demotion maior do que 50 ou se parar de anunciar completamente, então esse firewall tomaria novamente a liderança do mestre nos grupos carp1 e carp2.
Para voltar (fail back) para o firewall primário, reverta as mudanças:
# ifconfig -g internal -carpdemote 50
# ifconfig -g internal
internal: carp demote count 0
Daemons de rede como OpenBGPD e sasyncd(8) fazem uso do contador demotion para garantir que o firewall não se torne mestre até que as sessões BGP estejam estabelecidas e SAs IPsec estejam sincronizados.
pass in on fxp0 inet proto tcp from any to carp0 port 22mas substituir o fxp0 por carp0 não funcionaria como você deseja.
NÃO se esqueça de uma regra de permissão de tráfego para proto carp e proto pfsync!
[Anterior: Shell de Usuário para Gateways de Autenticação] [Conteúdo] [Próximo: Firewall para Casa ou Pequeno Escritório]