Duas gateways IPsec sem IP compartilhado: o que o failover realmente faz

Mate o gateway A durante uma reunião e veja o túnel voltar por B um minuto depois; a conexão funciona, a videochamada talvez não. Essa é a forma honesta do failover frio entre dois gateways IPsec com endereços independentes. O cliente seleciona novamente um endpoint e constrói uma nova relação, o que restaura a alcançabilidade sem transferir o estado criptográfico da sessão antiga. Percorrer a sequência deixa claro quais promessas o projeto pode cumprir.

Prepare o cenário: dois endereços, nenhum IP flutuante

O gateway A responde em um endereço alcançável e o gateway B em outro. O cliente tem uma forma aprovada de escolher B quando A desaparece, e não há um endereço externo compartilhado que ambos os gateways reivindiquem. Neste projeto, um IP virtual significa esse ponto de entrada compartilhado, não o endereço interno atribuído a um cliente de acesso remoto.

Essa definição importa porque as duas ideias se misturam nos tickets, e a correção de uma não é a correção da outra. Um relato de que a entrada compartilhada não seguiu o gateway descreve um projeto. Um relato de que o notebook perdeu seu endereço interno descreve o lease do cliente. Proprietários diferentes, registros diferentes, reparos diferentes.

Percorra a falha: detectar e depois selecionar novamente

Primeiro algo percebe que A parou de responder. Pode ser a detecção de par morto na camada de túnel, um protocolo de roteamento que retira um caminho, ou um tempo limite de aplicação que finalmente força uma reconexão. Cada um tem uma escala de tempo diferente, e o mais lento geralmente determina quanto tempo os usuários esperam.

Depois o cliente seleciona B por meio do mecanismo que a implantação suporta: um segundo remoto configurado, um nome DNS resolvido para um endereço saudável, ou roteamento que agora prefere outro caminho. A seleção é uma etapa de política, e precisa existir antes da falha, ou acontecerá por acidente.

O que B pode e não pode herdar

B pode compartilhar com A um modelo de configuração, uma autoridade de certificação e uma política de autenticação. Não pode herdar as associações de segurança ativas. As chaves de sessão, os índices de parâmetros de segurança e o estado de sequência pertencem à relação que A e o cliente estabeleceram, e B não tem nenhum deles.

Mover esse estado entre gateways é um problema real de engenharia, por isso a documentação de alta disponibilidade do strongSwan trata isso como um projeto de cluster e não como um sinalizador de configuração. Uma receita específica de cluster não é uma resposta genérica para uma rede em nuvem, e copiá-la sem a infraestrutura de apoio compra complexidade em vez de continuidade.

Estabelecer uma nova relação

Com B selecionado, o cliente realiza uma nova troca IKE: novos nonces, novos valores Diffie-Hellman, novos identificadores para as associações resultantes. A autenticação acontece novamente em B. Se o projeto depende de credenciais de máquina, a reconexão pode ser sem supervisão; se exige um fator humano, alguém precisa estar presente para que o failover se complete.

Defina essa experiência do usuário antes da interrupção, não durante. Diga claramente o que o cliente fará, quanto tempo tentará e o que mostrará quando desistir, porque a diferença entre um minuto de reconexão e uma ligação para o suporte costuma ser documentação e um perfil testado.

Preservar o mesmo endereço interno ajuda aplicações que esperam uma identidade local estável, e não preserva suas sessões. As ligações NAT expiram, as conexões TCP são redefinidas e qualquer coisa com seu próprio tempo limite decide por conta própria se tenta novamente.

Dois túneis em paralelo são um projeto diferente

Executar os dois túneis ao mesmo tempo é um padrão válido quando os dois gateways e o projeto de roteamento o suportam. A seleção de rota então escolhe o caminho ativo, e o caminho de volta precisa concordar, ou o tráfego sai por um gateway e volta pelo outro sem estado para combiná-lo.

Políticas de túnel sobrepostas não criam por si só um failover ordenado. Elas criam dois candidatos, e algo precisa decidir entre eles de forma determinística, seja uma métrica de roteamento, uma prioridade de política ou uma preferência explícita no cliente.

Qualquer que seja a forma escolhida, escreva o contrato: como a falha é detectada, como o alternativo é selecionado, que autenticação ele exige e quanto tempo a reconexão deve levar. Um IP compartilhado pode simplificar a descoberta, mas não é sinônimo de estado contínuo, e a disponibilidade é um projeto de qualquer forma.