![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Anterior: Shell de Usuário para Autenticação em Gateways] [Conteúdo] [Próximo: Firewall para Casa ou Pequeno Escritório]
CARP funciona permitindo a um grupo de hosts no mesmo segmento de rede compartilhar um endereço IP. Esse grupo de hosts é 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, um host é designado o "master" e o resto como "backups". O host "master" é o que atualmente "segura" o IP compartilhado; ele responde a qualquer tráfego ou requisições ARP direcionadas a ele. Cada host pode pertencer a mais que 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 (default). Caso o firewall master 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 Virtual Host ID que permite aos membros do grupo identificar que grupo de redundância pertencem.
Para prevenir que um usuário malicioso no segmento de rede falsifique (spoofing) 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 que o CARP está se comunicando.
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, comportamentos CARP podem ser controlados 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:
Rodar 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. Prática mais comum é:
Quando as atualizações estão sendo enviadas e recebidas na rede, os pacotes pfsync devem ser aceitos nas regras de filtragem.
pass on $sync_if proto pfsync
$sync_if deve ser a interface física que o pfsync(4) está se comunicando.
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 outro host rodando pfsync possa recebê-las.
Um cenário de exemplo. Dois firewalls, fw1 e fw2.
+----| WAN/Internet |----+
| |
em2| |em2
+-----+ +-----+
| fw1 |-em1----------em1-| fw2 |
+-----+ +-----+
em0| |em0
| |
---+-------Shared LAN-------+---
Os firewalls estão conectados diretamente usando um cabo crossover em em1. Ambos estão conectados a LAN em em0 e a uma conexão WAN/Internet em em2. Os endereços IP são como seguem:
A política de rede é que fw1 será o master preferido.
Configuração do fw1:
! Habilita preemption e o grupo de interfaces 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 no lado LAN
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
172.16.0.100 netmask 255.255.255.0
! Configura 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 preemption e o grupo de interfaces failover
# 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 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 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ó master. Isso fará o master anunciar a si mesmo com um advbase e advskew "infinito". O(s) host(s) backup verá(ão) isso e imediatamente tomará(ão) o lugar do master.
# ifconfig carp1 down
Uma alternativa é aumentar o advskew para um valor mais alto que o advskew no(s) host(s) backup. Isso causará failover, mas ainda permite ao master participar no grupo CARP.
Um outro método para failover é ajustar o contador CARP demotion. O contador demotion é uma medida de como "pronto" um host está para se tornar o master do grupo CARP. Por exemplo, enquanto um host está no meio do processo de boot é uma má idéia para ele se tornar um master CARP até que todas as interfaces estejam configuradas, todos os serviços de rede estejam iniciados, etc. Hosts anunciando um valor demotion alto terão menos preferência como master.
Um contador demotion é armazenado em cada grupo de interface que a interface CARP pertence. Por padrão, todas as interfaces CARP são membros do grupo de interface "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 um host CARP anuncia a si mesmo na rede, ele pega a soma dos contadores demotion para cada grupo de interface que a interface carp(4) pertence e anuncia esse valor como seu valor demotion.
Agora assuma o seguinte exemplo. Dois firewalls rodando 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 interface, neste caso chamado "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 fará elegantemente o failover nos grupos carp1 e carp2 para o outro firewall no cluster, enquanto ainda se mantém como master 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 fará novamente o takeover do master 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
Serviços de rede como OpenBGPD e sasyncd(8) fazem uso do contador demotion para garantir que o firewall não se torne master 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 substituindo o fxp0 por carp0 não funcionaria como você deseja.
NÃO se esqueça de uma regra pass para proto carp e proto pfsync!
[Anterior: Shell de Usuário para Autenticação em Gateways] [Conteúdo] [Próximo: Firewall para Casa ou Pequeno Escritório]
![[voltar]](../../../images/back.gif){kind=small}
www@openbsd.org