Renovação de chave, reconexão ou reautenticação: qual precisa?

Uma sessão ativa há horas não manterá as mesmas chaves para sempre, e isso é intencional. Três eventos diferentes são chamados de rotação de chaves: novo material de sessão sob uma associação existente, uma reconstrução completa da conexão e uma repetição da verificação de identidade. Cada um tem um gatilho, um custo e uma assinatura de falha diferentes. Escolha o errado e a correção ou não faz nada ou derruba o túnel sem motivo.

A decisão depende de qual camada realmente expirou.

Três operações chamadas de rotação

Uma renovação de chave cria novas chaves de tráfego dentro da relação de controle existente, usando o mecanismo definido pelo protocolo. O IKEv2 faz isso com uma nova associação de segurança filha, o TLS 1.3 com uma mensagem de atualização de chave e o WireGuard com um novo handshake quando seus limites de tempo ou de mensagens são atingidos. Os endereços do túnel e a identidade autenticada ficam onde estavam.

Uma reconexão descarta a conexão e a reconstrói do início, o que repete a atribuição de endereços, a instalação de rotas e qualquer negociação feita pela primeira tentativa.

A reautenticação repete a própria prova de identidade, que pode envolver uma credencial, um certificado ou um segundo fator. Pode ocorrer com ou sem reconexão, dependendo do produto.

O que os usuários notam na renovação

Uma renovação de chave deve ser quase invisível. Os identificadores de associação mudam, os contadores podem ser redefinidos e as aplicações mantêm seus sockets; uma pausa breve numa direção é normal durante a troca. Ver um novo identificador numa lista de estado não é prova de falha. A linha de log que segue a troca é o que diz se ela terminou.

Uma queda real na renovação aponta para um ponto específico. Incompatibilidade de proposta, credencial expirada ou mudança de caminho produzem cada um uma linha de log diferente, e apenas um deles é corrigido ajustando as durações.

Onde as três divergem na prática

Se a única coisa que expirou foi o material da chave, renove a chave. Se o endereço do par, a rota ou a ligação NAT mudaram e os pacotes já não chegam, reconecte. Se a organização exige uma verificação periódica de identidade, isso é reautenticação e nenhum ajuste de durações a substitui.

Os valores padrão dos protocolos geralmente contêm a resposta certa. O WireGuard renova chaves após um limite de tempo e de volume de dados sem ação do usuário; as durações do IKEv2 são negociadas por associação filha; os túneis baseados em TLS rodam chaves dentro da sessão existente. Aumentar as durações para evitar um erro recorrente adia a falha e prolonga a exposição se uma chave for comprometida.

Um alerta é importante para sessões longas: a frequência por si só não cria sigilo persistente. A propriedade depende de como as chaves de sessão se relacionam com os segredos de longo prazo e de se as chaves antigas são destruídas, o que é uma questão de projeto e implementação, não de configuração.

Escolha os valores padrão e depois registre a etapa

Mantenha os valores padrão do fornecedor, a menos que um requisito documentado diga o contrário, e altere as durações nos dois pares se as alterar. Depois registre a que etapa cada evento chegou, para que a próxima ocorrência possa ser comparada com o mesmo ponto do handshake.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Após uma correção, faça uma renovação controlada e envie tráfego de aplicação novo pela nova associação. Um túnel que se declara estabelecido mas não encaminha nada é a falha que esta verificação existe para apanhar.