IKEv2: renovação de chaves versus reautenticação — por que a conexão cai mais tarde

O túnel sobe pela manhã e funciona por horas. Depois cai, reconecta após uma tentativa e faz o mesmo no dia seguinte. Nada mudou na rede e ninguém tocou numa senha. As sessões que falham numa fronteira de renovação normalmente cruzam uma de duas operações diferentes, e só uma delas verifica novamente suas credenciais. Ler qual das duas foi disparada é todo o diagnóstico.

Duas operações que parecem iguais de fora

A renovação de chaves substitui associações de segurança ou material de chaves dentro da troca definida pelo protocolo. A autenticação não é repetida, então a identidade aceita no início da sessão é simplesmente levada adiante.

A reautenticação vai além: estabelece uma nova relação autenticada, o que significa que as credenciais são avaliadas de novo. Tudo o que expirou, foi revogado ou mudou no diretório torna-se visível naquele momento.

O que uma renovação de chaves realmente substitui

O IKEv2 mantém dois tipos de associação com ciclos de vida separados. A IKE SA protege o canal de controle, e as CHILD SA protegem o tráfego real. Renovar uma não é sinônimo de reconectar o cliente.

Essa separação explica um padrão conhecido: o tráfego flui bem, depois uma CHILD SA é renovada e a proposta não corresponde mais porque alguém editou a fase 2 de um lado semanas antes. A mudança ficou ali inofensiva até a renovação exercitá-la.

Descompassos de duração comportam-se da mesma forma. O par que atinge primeiro seu limite inicia a troca, e o outro precisa aceitá-la.

O que a reautenticação reavalia

Com a reautenticação, o certificado de cliente que era válido no login pode agora estar expirado. Uma credencial revogada, uma senha rotacionada ou um segundo fator indisponível aparecem todos aqui, não no momento da renovação.

Por isso alongar cada duração parece uma correção e não é. Você adiou a verificação em vez de passá-la. A próxima renovação chega com o mesmo defeito e uma janela de interrupção mais curta para percebê-lo.

Algumas implementações sobrepõem estado antigo e novo durante a reautenticação. Outras produzem uma lacuna breve. Por isso, ajustes idênticos em dois fornecedores podem dar experiências de usuário diferentes. Teste o comportamento em vez de supor que o padrão o determina.

Leia os carimbos de tempo antes de mudar qualquer coisa

Capture o momento da falha junto com o estado da associação antes e depois. Se a associação antiga foi substituída sem uma troca de autenticação, você estava numa fronteira de renovação. Se uma troca AUTH aparece logo antes da falha, você estava numa reautenticação.

O strongSwan expõe isso como ajustes separados: rekey controla a renovação de chaves, reauth controla se ocorre uma nova autenticação, e os valores de margem decidem com quanta antecedência ao vencimento cada uma começa. a documentação sobre a renovação de chaves descreve a interação, e vale a pena lê-la antes de copiar uma duração de uma postagem de fórum.

Distinga tudo isso de uma perda de rede simples. Um link cortado produz um evento de detecção de par morto ou uma tempestade de retransmissões, não uma troca limpa com propostas correspondentes.

Mude o que falhou

Uma rejeição de credenciais exige corrigir o problema de identidade: renove o certificado, restaure a conta, registre novamente o fator. Um descompasso de proposta ou de duração exige comparar os parâmetros dos dois lados.

Esticar as durações para evitar o sintoma é a única opção que sempre parece ter funcionado e nunca funciona.

Teste uma renovação controlada

Force a renovação em vez de esperar um dia por ela. Depois repita com uma reautenticação se a implantação suportar uma, e observe as duas pontas.

Um login inicial bem-sucedido não exercita nada disso. O ciclo de vida posterior é onde essas implantações realmente quebram.