Por que um túnel IPsec ocupado renova as chaves cedo: limites de tempo e de volume

Aproximadamente a cada cinquenta minutos, um túnel numa ligação ocupada cai durante alguns segundos, e o primeiro suspeito é o relógio. As associações podem terminar por um limite de tempo ou por uma contagem de bytes, e a fronteira que chegar primeiro é a que as aposenta. Numa ligação que transporta tráfego real, um limite de volume pode disparar muito antes de a hora configurada terminar. Portanto, «cedo demais» é uma afirmação sobre o relógio, não sobre a associação.

Conte o que a associação conta, não a interface

O total de bytes de uma interface, o caudal combinado de um painel e o contador próprio da associação são três números separados, e apenas um deles é comparado com o limite. Registe as associações de entrada e de saída separadamente com os seus identificadores, para que uma mudança de chaves que toque uma direção apareça como um evento direcional em vez de um mistério. O contador da associação também recomeça na mudança de chaves, e é por isso que um total retirado da interface cresce enquanto o valor que importa é reposto.

Vale a pena fazer a aritmética uma vez, para que a ordem de grandeza deixe de parecer arbitrária. Um orçamento contado de um gibibyte esgotado a um ritmo constante de 128 mebibytes por minuto consome-se em oito minutos, e isso é uma conversão de unidades, não uma medição do seu túnel. Se a cifra resultante ficar muito abaixo do limite de tempo, o volume é o mecanismo e nenhuma observação do relógio explicará o intervalo. Se ficar muito acima, o limite de bytes não é o seu gatilho e a procura pertence a outro lugar.

Os limiares suave e rígido são dois eventos diferentes

Um limiar suave pede uma substituição muito antes de o limite rígido terminar a associação, e as implementações acrescentam as suas próprias margens e aleatoriedade por cima do que configurou. É por isso que o intervalo observado quase nunca é um número redondo. A arquitetura IPsec descreve vidas úteis expressas em tempo e contagens de bytes com os dois tipos de limiar, e prevalece a expiração mais precoce. Se tratar uma vida útil impressa como um calendário, errará a dimensão da margem.

Leia a política efetiva do estado em execução em vez de a inferir de um número num ficheiro, porque a margem pertence à implementação, não à sua intenção. Resista à tentação de esticar os limites até ao máximo para silenciar o sintoma: um túnel que muda de chaves segundo o calendário comporta-se como foi projetado, e uma vida útil mais longa apenas adia o evento, mantendo uma chave comprometida utilizável durante mais tempo. Quando a própria substituição falha, o limite é o mensageiro e não a culpa.

Leia a vida útil efetiva do estado em execução

No strongSwan, swanctl --list-sas imprime o resumo da associação com os tempos de mudança de chaves e de vida, pelo que o valor que o daemon pretende impor é visível sem adivinhar. Num anfitrião Linux sem vista do daemon, ip xfrm state relata os limites suaves e rígidos de bytes e pacotes configurados ao lado dos contadores atuais. Essas duas leituras respondem a perguntas diferentes e ambas merecem ficar no ticket.

swanctl --list-sas
ip -s xfrm state

Compare o limiar suave impresso com o intervalo que mediu, porque uma substituição que começa com uma margem abaixo do limite rígido é normal e uma que nunca começa não é. Se o daemon mostra uma vida útil e o estado do kernel mostra outra, está a olhar para duas camadas que não concordam, e isso mesmo é o achado.

Observe a troca que substitui a SA

Mantenha as três renovações separadas, porque falham de formas diferentes: uma mudança de chaves de IKE SA constrói uma nova associação de controlo, uma mudança de chaves de CHILD SA substitui a associação de dados, e a reautenticação repete a troca de identidade. No IKEv2 cada par decide as suas próprias vidas úteis em vez de negociar um valor partilhado, por isso uma troca que não iniciou é normal. Uma discrepância de perfect forward secrecy é uma causa frequente de uma nova child SA morrer exatamente no intervalo de mudança de chaves, e apresenta-se exatamente como uma falha de temporizador até alguém ler a proposta.

Compare a associação antiga com a sua sucessora e com a troca que a produziu. Um identificador que desaparece é uma substituição rotineira; uma proposta rejeitada, uma resposta ausente ou a falta de um estado sucessor utilizável é um evento diferente com outro proprietário. Preserve essas provas antes de mudar seja o que for, porque as notas específicas da versão, a proposta do par e as vidas úteis negociadas são o que torna o caso legível uma semana depois, quando os registos já rodaram.

Prove a renovação em vez de escondê-la

Aceite a implementação passando por uma renovação que planeou e não por uma que lhe acontece. Force uma única mudança de chaves dentro de uma janela de manutenção e depois confirme que ambas as direções transportam dados e que o resultado da aplicação não mudou, não apenas que o indicador do túnel está verde. Registe que limite disparou e que troca esteve envolvida.

Uma conclusão dessa forma sobrevive ao escrutínio, enquanto um valor de temporizador alterado que fez a ligação parecer calma durante uma tarde não sobrevive. Se só o temporizador se mexeu, as provas mexeram-se com ele.