Alta disponibilidade multinodo

Grupos de redundância de serviços

Um grupo de redundância de serviços (SRG) é uma unidade de failover em uma configuração multinode de alta disponibilidade. Existem dois tipos de SRGs:

• SRG0 — gerencia o serviço de segurança a partir da Camada 4-Camada 7, exceto os serviços de VPN IPsec. O SRG0 opera no modo ativo em ambos os nós a qualquer momento. No SRG0, cada sessão de segurança deve atravessar o nó em um fluxo simétrico, o backup desses fluxos é totalmente sincronizado em estado para o outro nó,
• SRG1+— gerencia serviços IPsec e IPs virtuais para o modo gateway híbrido e padrão e tem backup do outro nó. O SRG1 opera no modo ativo em um nó e em nó de backup em outro nó.

A Figura 10 mostra o SRG0 e o SRG1 em uma configuração de alta disponibilidade multinodo.

Figura 10: Suporte SRG único em alta disponibilidade multinodo (modo active-backup)

A Figura 11 mostra o SRG0 e o SRG1+ em uma configuração de alta disponibilidade multinodo.

Figura 11: Suporte multi-SRG em alta disponibilidade multinodo (modo ativo-ativo)

A partir do Junos OS Release 22.4R1, você pode configurar o Multinode High Availability para operar no modo ativo com suporte de multi SRG1s (SRG1+). Nesse modo, alguns SRGs permanecem ativos em um nó e alguns SRGs permanecem ativos em outro nó. Um SRG específico sempre opera no modo active-backup; opera no modo ativo em um nó e modo de backup em outro nó. Neste caso, ambos os nós podem ter o SRG1 ativo encaminhando serviços stateful. Cada nó tem um conjunto diferente de endereços IP flutuantes atribuídos ao SRG1+.

A Tabela 3 explica o comportamento dos SRGs em uma configuração de alta disponibilidade multinodo.

A partir do Junos OS Release 23.4R1, a configuração multinodo de alta disponibilidade opera em um modo combinado. Você não precisa reiniciar o sistema ao adicionar ou excluir nenhuma configuração de SRG (SRG0 ou SRG1+).

Determinação e aplicação da ativação

Em uma configuração multinode de alta disponibilidade, a ativação é determinada no nível de serviço, não no nível do nó. O estado ativo/backup está no nível SRG e o tráfego é direcionado para o SRG ativo. O SRG0 permanece ativo em ambos os nós, enquanto o SRG1 pode permanecer ativo ou em estado de backup em cada nó

Se você preferir que um determinado nó assuma o cargo de nó ativo no boot, você pode fazer um dos seguintes:

• Configure os roteadores upstream para incluir preferências pelo caminho onde o nó está localizado.
• Configure a prioridade de ativação.
• Permita que o nó com ID de nó mais alto (caso as duas opções acima não estiverem configuradas) assumam a função ativa.

Em uma configuração multinode de alta disponibilidade, ambos os firewalls da Série SRX anunciam inicialmente a rota para o endereço IP flutuante para os roteadores upstream. Não há uma preferência específica entre os dois caminhos anunciados pelos firewalls da Série SRX. No entanto, o roteador pode ter suas próprias preferências em um dos caminhos, dependendo das métricas configuradas.

A Figura 12 representa a sequência de eventos para determinação da ativação e aplicação da ativação.

Figura 12: Determinação e aplicação da ativação

1. No boot, os dispositivos entram no estado de espera e começam a sondar continuamente. Os dispositivos usam o endereço IP flutuante (endereço IP de origem de sondagem de ativação) como endereço IP de origem e endereços IP dos roteadores upstream como endereço IP de destino para a sondagem de determinação de ativação.

2. O roteador que hospeda o endereço IP de destino da sonda responde ao firewall da Série SRX que está disponível em seu caminho de roteamento preferido. No exemplo a seguir, o SRX-1 recebe a resposta do roteador upstream.

   Figura 13: Determinação e aplicação da ativação

3. O SRX-1 se promove para o papel ativo desde que recebeu a resposta da sonda. O SRX-1 comunica sua mudança de função para o outro dispositivo e assume a função ativa.

4. Após a ativação ser determinada, o nó ativo (SRX-1):

   • Hospeda o endereço IP flutuante atribuído a ele.
   • Anuncia o caminho de alta preferência para vizinhos BGP adjacentes.
   • Continua anunciando o caminho de preferência ativo (superior) para todas as rotas remotas e locais para atrair o tráfego.
   • Notifica o status de nó ativo para o outro nó por meio da ICL.

5. O outro dispositivo (SRX-2) para de sondar e assume a função de backup. O nó de backup anuncia a prioridade padrão (menor), garantindo que os roteadores upstream não encaminhem nenhum pacote para o nó de backup.

O módulo multinodo de alta disponibilidade adiciona rotas de sinal ativas e de backup para o SRG à tabela de roteamento quando o nó se move para a função ativa. Em caso de falhas de nó, a ICL cai e o nó ativo atual libera sua função ativa e remove a rota de sinal ativa. Agora, o nó de backup detecta a condição por meio de suas sondas e faz a transição para a função ativa. A preferência de rota é trocada para conduzir todo o tráfego em direção ao novo nó ativo.

O switch no anúncio de preferência de rota faz parte das políticas de roteamento configuradas em firewalls da Série SRX. Você deve configurar a política de roteamento para incluir a rota de sinal ativa com a if-route-exists condição.

• Para implantações de gateway padrão
• Para implantações híbridas
• Prioridade e preempção da ativa
• Configuração das configurações da sondagem de ativação

Resiliência e failover

A solução multinodo de alta disponibilidade oferece suporte a redundância no nível de serviço. A redundância de nível de serviço minimiza o esforço necessário para sincronizar o plano de controle em todos os nós.

Após a configuração de alta disponibilidade multinodo determinar a ativação, ele negocia o estado subsequente de alta disponibilidade (HA) por meio da ICL. O nó de backup envia sondas ICMP usando o endereço IP flutuante. Se a ICL estiver ativa, o nó recebe a resposta à sua sonda e permanece como o nó de backup. Se a ICL estiver baixa e não houver resposta à sonda, o nó de backup faz a transição para o nó ativo.

O SRG1 do nó de backup anterior agora faz a transição para o estado ativo e continua operando perfeitamente. Quando a transição acontece, o endereço IP flutuante é atribuído ao SRG1 ativo. Dessa forma, o endereço IP flutua entre os nós ativos e de backup e permanece acessível a todos os hosts conectados. Assim, o tráfego continua fluindo sem qualquer interrupção.

Serviços, como a VPN IPsec, que exigem estados de plano de controle e plano de dados são sincronizados entre os nós. Sempre que um nó ativo falha nessa função de serviço, tanto o plano de controle quanto o plano de dados falham no nó de backup ao mesmo tempo.

Os nós usam as seguintes mensagens para sincronizar dados:

• Mensagens de aplicativo de controle do mecanismo de roteamento para roteamento
• Mensagens relacionadas à configuração do mecanismo de roteamento
• Mensagens de RTO de plano de dados

Criptografia do link de interchassis (ICL)

Em multinodos de alta disponibilidade, os nós ativos e de backup comunicam-se entre si usando um link de interchasse (ICL) conectado em uma rede roteada ou conectado diretamente. O ICL é um enlace IP lógico e está estabelecido usando endereços IP que são roteáveis na rede.

Nós usam a ICL para sincronizar os estados de plano de controle e plano de dados entre eles. A comunicação da ICL pode passar por uma rede compartilhada ou não confiável e os pacotes enviados pela ICL podem percorrer um caminho que nem sempre é confiável. Portanto, você deve proteger os pacotes que atravessam a ICL criptografando o tráfego usando padrões IPsec.

O IPsec protege o tráfego estabelecendo um túnel de criptografia para a ICL. Quando você aplica a criptografia de enlace de HA, o tráfego de HA flui entre os nós apenas através do túnel seguro e criptografado. Sem criptografia de enlaces HA, a comunicação entre os nós pode não ser segura.

Para criptografar o link HA para a ICL:

• Instale o pacote Junos IKE em seu firewall da Série SRX usando o seguinte comando:

  request system software add optional://junos-ike.tgz .

• Configure um perfil de VPN para o tráfego HA e aplique o perfil para ambos os nós. O túnel IPsec negociado entre os firewalls da Série SRX usa o protocolo IKEv2.

• Certifique-se de ter incluído a declaração ha-link-criptografia em sua configuração de VPN IPsec. Exemplo: user@host# definir segurança ipsec vpn vpn-name ha-link-criptografia.

Recomendamos seguir a configuração de uma ICL:

• Use portas e redes que são menos propensas a serem saturadas
• Para não usar as portas HA dedicadas (portas de controle e malha, se disponíveis em seu firewall da Série SRX)

• Conecte o ICL à interface de loopback (lo0) ou a uma interface Ethernet agregada (ae0) e tenha mais de um link físico (LAG/LACP) que garante a diversidade de caminhos para maior resiliência.

• Você pode usar uma porta Ethernet de receita nos firewalls da Série SRX para configurar uma conexão ICL. Certifique-se de separar o tráfego de trânsito em interfaces de receita do tráfego de alta disponibilidade (HA).

Veja configurando a alta disponibilidade multinodo para obter mais detalhes.

Criptografia de link baseada em PKI para ICL

A partir do Junos OS Release 22.3R1, oferecemos suporte à criptografia de link baseada em PKI para link de interchassis (ICL) em alta disponibilidade multinodo. Como parte desse suporte, agora você pode gerar e armazenar objetos PKI específicos de nós, como keypairs locais, certificados locais e solicitações de assinatura de certificados em ambos os nós. Os objetos são específicos para nós locais e são armazenados nos locais específicos em ambos os nós.

Os objetos locais de nó permitem que você distingue entre objetos PKI que são usados para criptografia ICL e objetos PKI usados para túnel VPN IPsec criado entre dois endpoints.

Você pode usar os seguintes comandos executados em nó local para trabalhar com objetos PKI específicos de nós.

Em seu dispositivo de segurança em Multinode High Availability, se você tiver configurado a opção de recadastramento automático e se a ICL cair no momento da rematrícula, ambos os dispositivos começam a inscrever o mesmo certificado separadamente com o servidor CA e baixam o mesmo arquivo CRL. Uma vez que a alta disponibilidade multinodo restabeleça a ICL, a configuração usa apenas um certificado local. Você deve sincronizar os certificados do nó ativo ao nó de backup usando o user@host> request security pki sync-from-peer comando no nó de backup.

Se você não sincronizar os certificados, o problema de incompatibilidade do certificado entre nós de pares persiste até a próxima rematrícula.

Opcionalmente, você pode habilitar o TPM (módulo de plataforma confiável) em ambos os nós antes de gerar quaisquer keypairs nos nós. Veja usando módulo de plataforma confiável para vincular segredos em dispositivos da Série SRX.

Sondagem split-brain baseada em ICMP

Considere um cenário em que dois dispositivos da Série SRX fazem parte da configuração de alta disponibilidade multinodo. Vamos considerar o SRX-1 como nó local e nó remoto SRX-2. O nó local está atualmente em função ativa e hospedando endereço IP flutuante para direcionar o tráfego em direção a ele. O roteador upstream tem um caminho de maior prioridade para o nó local.

Quando a ICL entre os nós cai, ambos os nós iniciam uma sonda de determinação de ativação (sonda ICMP). Os nós usam o endereço IP flutuante (endereço IP de determinação de ativação) como endereço IP de origem e endereços IP dos roteadores upstream como endereço IP de destino para as sondas.

Caso 1: se o nó ativo estiver ativo ativa

Figura 14: o nó ativo está em alta e a ICL está baixa

• O roteador upstream, que hospeda o endereço IP de destino da sonda, recebe as sondas ICMP de ambos os nós.
• O roteador upstream responde apenas ao nó ativo; porque sua configuração tem um caminho de preferência mais alto para o nó ativo
• O nó ativo mantém a função ativa.

Se o nó ativo estiver desativado:

Figura 15: o nó ativo está desativado e a ICL está baixa

• O nó remoto reinicia as sondas de determinação de ativação.
• O roteador que hospeda o endereço IP de destino da sonda perdeu seu caminho de preferência mais alto (do antigo nó ativo) e responde ao nó remoto.
• O resultado da sonda é um sucesso para o nó remoto e as transições de nó remoto para o estado ativo.
• Como demonstrado nos casos acima, as sondas de determinação de ativação e a configuração de maior preferência de caminho no roteador upstream garantem que um nó sempre permaneça na função ativa e evita que o cérebro dividido ocorra.

Sondagem de cérebro dividido baseada em BFD

No Junos OS Release 23.4R1, oferecemos suporte a sondagem split-brain baseada em BFD para implantações de gateway padrão e híbridas para alta disponibilidade multinodo.

A falha no Link de Interchassis (ICL) pode muitas vezes ser atribuída a dois fatores-chave: interrupções de rede ou configurações inconsistentes. Você pode usar a sonda de ativação para determinar o nó que pode assumir uma função ativa para cada SRG1+. Com base no resultado da sonda, um dos nós faz transições para o estado ativo e essa ação evita cenários cerebrais derramados.

Com a sondagem de cérebro dividido baseada em BFD, agora você pode ter mais controle granular nas sondas, pois pode definir a interface, o intervalo mínimo e os multiplicadores. Na sondagem de cérebro dividido baseada em BFD, a sondagem começa imediatamente após a configuração de um SRG e começa a funcionar. Na sondagem de cérebro dividido baseada em ICMP padrão, a sondagem só começa depois que o link ICL cai.

Em comparação, a sondagem baseada em BFD é muito mais proativa das seguintes maneiras para garantir uma resposta mais rápida para evitar cenários de cérebro dividido:

• A sondagem inicia diretamente a publicação de uma configuração de SRG.

• Se tanto a ICL BFD quanto a sonda split-brain quebrarem ao mesmo tempo, o nó de backup assume imediatamente o papel ativo e assume o VIP.

Isso garante uma resposta mais rápida para evitar cenários de cérebro dividido.

• Como funciona?
• Diferença na sondagem baseada em ICMP e baseada em BFD

show chassis 
high-availability services-redundancy-group 1 
activeness-probe
dest-ip {
    192.168.21.1; 
    src-ip 192.168.21.2;
    }

show chassis 
high-availability services-redundancy-group 1 
activeness-probe
bfd-liveliness {
    source-ip 192.168.21.1; (inet address of the local SRX sub interface) 
    destination-ip 192.168.21.2; (inet address of the peers SRX sub interface) 
    interface xe-0/0/1.0;     
}

A figura a seguir mostra opções de configuração para sondagem baseada em ICMP e sondagem baseada em BFD para detecção de cérebro dividido.

Figura 16: Configuração de activeness-probes para sondagem baseada em ICMP e baseada em BFD

No modo híbrido e implantações de gateway padrão, você pode configurar o intervalo e o limiar da sonda de ativação a seguir dois níveis:

• Nível global aplicável à sondagem de cérebro dividido baseada em ICMP

• Nível de BFD-Liveliness que é específico da sonda BFD split-brain. Ao configurar a sondagem baseada em BFD, não configure o global minimum-interval e multiplier as opções em activeness-probe declaração.

Para configurar a sonda de ativação para implantações de gateway padrão, use a interface de endereço virtual principal (VIP1) em ambos os nós (local e peer) para configurar sua sonda de ativação. O IP de destino é do nó peer, e o IP de origem é do seu nó local. Ambos os VIPs devem ter o mesmo valor de índice. Os endereços IP devem ser os endereços de inet atribuídos à interface LAN do firewall da Série SRX.

Configure a sondagem split-brain

• Configuração de amostra
• Verificação

Figura 17: Configuração de alta disponibilidade multinodo para sondagem split-brain

Vamos considerar o SRX-1 como um nó local e SRX-2 como um nó remoto. O nó local está atualmente em função ativa e o roteador upstream tem um caminho de prioridade maior para o nó local.

Para a sondagem de ativação, você deve configurar as seguintes opções:

• Endereço IP de origem: Use o endereço IP virtual 1 (VIP1) do SRG1 do nó local.

• Endereço IP de destino: Use o VIP1 do SRG1 do nó peer.

• Interface: Interface associada ao VIP1

Neste exemplo, atribua um endereço IP virtual (VIP) (192.168.21.1) e uma interface xe-0/0/1.0 para a livelines BFD. Aqui, você configura a sondagem split-brain baseada em BFD especificando endereços IP de origem e destino e a interface.

Os nós usam o endereço de inet da família da interface associada ao endereço IP virtual (VIP1) do SRG1.

Ambos os nós iniciam uma sonda de determinação de ativação (sonda baseada em BFD) assim que os SRGs começam a operar.

A tabela a seguir mostra como a configuração de alta disponibilidade multinodo resolve a situação do cérebro dividido com sondagem baseada em BFD quando a ICL está baixa. Dependendo dos estados de nó e dos resultados da sondagem, o sistema multinodo de alta disponibilidade seleciona o nó para assumir a função ativa.

A Tabela 6 mostra como a configuração de alta disponibilidade multinodo resolve a situação de cérebro dividido com sondagem baseada em BFD quando a ICL está baixa. Dependendo dos estados de nó e dos resultados da sondagem, o sistema multinodo de alta disponibilidade seleciona o nó para assumir a função ativa.

Neste exemplo, assumimos que o SRG1 do nó 1 tem a maior prioridade de ativação.

• Use o show chassis high-availability services-redundancy-group 1 comando para ver o tipo de sonda split-brain configurada no dispositivo.

  (Sondagem baseada em BFD) (Sondagem baseada em ICMP)

• Use o show bfd session comando para ver se o status da sondagem baseada em BFD.

  Na amostra, você pode notar que a sondagem de cérebro dividido baseada em BFD está sendo executada para interface xe-0/0/1,0.

• Use o show chassis high-availability services-redundancy-group 1 comando para obter os detalhes das sondas baseadas em BFD.