Alta Disponibilidade
- Visão geral do pfsync
- Visão geral da sincronização de configuração do pfSense XML-RPC
- Exemplo de Configuração Redundante
- Multi-WAN com HA
- Verificando a funcionalidade de failover
- Fornecendo Redundância Sem NAT
- Redundância da Camada 2
- Alta Disponibilidade com Bridging
- Usando Aliases de IP para Reduzir o Tráfego de Heartbeat
- Interface
- Solução de problemas de alta disponibilidade
O pfSense é uma das poucas soluções de software livre que oferece recursos de alta disponibilidade de classe empresarial com failover estável, permitindo a eliminação do firewall como um único ponto de falha. A alta disponibilidade é obtida por meio de uma combinação de recursos:
- CARP para redundância de endereço IP
- XMLRPC para sincronização de configuração
- pfsync para sincronização de tabelas de estado
Com essa configuração, as unidades agem como um cluster “ativo / passivo”, com o nó primário trabalhando como unidade mestre e o nó secundário em uma função de backup, assumindo o controle conforme necessário, se o nó primário falhar.
Embora muitas vezes erroneamente chamado de “CARP Cluster”, dois ou mais firewalls pfSense redundantes são mais adequadamente chamados de “High Availability Cluster” ou “HA Cluster”, já que o CARP é apenas uma das várias tecnologias usadas para atingir alta disponibilidade com pfSense e o futuro CARP poderia ser trocado por um protocolo de redundância diferente.
Uma interface em cada nó do cluster será dedicada para tarefas de sincronização. Isso é normalmente chamado de interface “Sync” e é usado para sincronização de configuração e sincronização de estado pfsync. Qualquer interface disponível pode ser usada.
Alguns chamam isso de interface “CARP”, mas isso é incorreto e muito enganador. Os batimentos cardíacos do CARP acontecem em cada interface com um CARP VIP; O tráfego CARP e as ações de failover não utilizam a interface Sync.
A configuração de cluster mais comum de alta disponibilidade inclui apenas dois nós. É possível ter mais nós em um cluster, mas eles não fornecem uma vantagem significativa.
É importante distinguir entre as três funções (redundância do endereço IP, sincronização da configuração e sincronização da tabela de estados), porque elas acontecem em locais diferentes. A sincronização de configuração e a sincronização de estado ocorrem na interface de sincronização, comunicando-se diretamente entre as unidades de firewall. Os batimentos cardíacos do CARP são enviados em cada interface com um CARP VIP. A sinalização de failover não acontece na interface de sincronização, mas acontece em todas as interfaces ativadas pelo CARP.
Visão geral do CARP
O CARP (Common Address Redundancy Protocol) foi criado pelos desenvolvedores do OpenBSD como uma solução gratuita de redundância aberta para o compartilhamento de endereços IP entre um grupo de dispositivos de rede. Soluções semelhantes já existiam, principalmente o padrão IETF para Virtual Router Redundancy Protocol (VRRP). No entanto, a Cisco afirma que o VRRP é coberto por sua patente em seu Hot Standby Router Protocol (HSRP), e disse aos desenvolvedores do OpenBSD que aplicaria sua patente. Assim, os desenvolvedores do OpenBSD criaram um novo protocolo aberto e gratuito para realizar essencialmente o mesmo resultado sem infringir a patente da Cisco. O CARP tornou-se disponível em outubro de 2003 no OpenBSD, e mais tarde foi adicionado ao FreeBSD também.
Um endereço IP virtual do tipo CARP (VIP) é compartilhado entre os nós de um cluster. Um nó é mestre e recebe tráfego para o endereço IP, e os outros nós mantêm o status de backup e monitoram as pulsações para ver se precisam assumir a função de mestre se o mestre anterior falhar. Como apenas um membro do cluster por vez está usando o endereço IP, não há conflito de endereço IP para os VIPs do CARP.
Para que o failover funcione corretamente, é importante que o tráfego de entrada que chega ao cluster, como tráfego upstream roteado, VPNs, NAT, gateway de cliente local, solicitações DNS, etc., seja enviado a um VIP CARP e para tráfego de saída, como NAT de saída a ser enviado de um VIP do CARP. Se o tráfego for endereçado diretamente a um nó e não a um VIP do CARP, esse tráfego não será captado por outros nós.
O CARP funciona de maneira semelhante ao VRRP e ao HSRP e pode até mesmo entrar em conflito em alguns casos. As pulsações são enviadas em cada interface contendo um CARP VIP, uma pulsação por VIP por interface. Nos valores padrão para skew e base, um VIP envia pulsações uma vez por segundo. A inclinação determina qual nó é o mestre em um determinado ponto no tempo. Qualquer que seja o nó que transmita pulsações, o mais rápido assume a função de mestre. Um valor de inclinação superior faz com que os batimentos cardíacos sejam transmitidos com mais atraso, portanto, um nó com uma inclinação inferior será o mestre, a menos que uma rede ou outro problema cause atrasos ou perdas para os heartbeats.
Nunca acesse a GUI do firewall, o SSH ou outro mecanismo de gerenciamento usando um CARP VIP. Para fins de gerenciamento, use somente o endereço IP real na interface de cada nó separado e não no VIP. Caso contrário, não pode ser determinado antecipadamente qual unidade está sendo acessada.
Requisitos de endereço IP para o CARP
Um cluster de alta disponibilidade usando o CARP precisa de três endereços IP em cada sub-rede, juntamente com uma sub-rede não usada separada para a interface do Sync. Para WANs, isso significa que uma sub-rede / 29 ou maior é necessária para uma configuração ideal. Um endereço IP é usado por cada nó, além de um endereço VIP compartilhado do CARP para failover. A interface de sincronização requer apenas um endereço IP por nó.
É tecnicamente possível configurar uma interface com um VIP CARP como o único endereço IP em uma determinada sub-rede, mas geralmente não é recomendado. Quando usado em uma WAN, esse tipo de configuração só permitirá a comunicação do nó primário para a WAN, o que complica muito as tarefas, como atualizações, instalações de pacotes, monitoramento de gateway ou qualquer coisa que exija conectividade externa do nó secundário. Pode ser melhor para uma interface interna, no entanto interfaces internas normalmente não sofrem as mesmas limitações de endereço IP que uma WAN, então ainda é preferível configurar endereços IP em todos os nós.
Preocupação com Switch / Layer 2
As pulsações CARP utilizam multicast e podem requerer manuseio especial nos switches envolvidos com o cluster. Alguns switches filtram, limitam ou interferem de alguma forma com multicast de maneiras que podem causar a falha do CARP. Além disso, alguns switches empregam métodos de segurança de porta que podem não funcionar corretamente com o CARP.
No mínimo, o comutador deve:
- Permita que o tráfego Multicast seja enviado e recebido sem interferência nas portas usando VIPs do CARP.
- Permitir que o tráfego seja enviado e recebido usando vários endereços MAC.
- Permita que o endereço MAC VIP do CARP se mova entre as portas.
Quase todos os problemas com o CARP não refletem adequadamente o status esperado são falhas do switch ou outros problemas da camada 2, portanto, certifique-se de que os switches estejam configurados corretamente antes de continuar.