Porque o seu túnel IPsec funciona até à primeira renovação de chave CHILD SA

O túnel subiu, o ping respondeu e todos deram o aval. Quatro horas depois a sessão cai, os pares registam um erro de proposta ou de troca de chaves, e a primeira suposição é que algo mudou na rede. Nada mudou. Um túnel que transporta tráfego provou que os dois pares concordam em como autenticar e como proteger a primeira associação filha, e não provou nada sobre a troca de chaves que vão exigir na renovação. A incompatibilidade está no intervalo entre esses dois eventos.

Ligado não significa que as definições de PFS concordam

Com IKEv2, a primeira associação filha é criada durante a troca de autenticação, e as suas chaves derivam de material que a associação IKE já produziu. Não ocorre uma troca Diffie-Hellman separada para essa filha, pelo que uma política que a exija na renovação não é testada no arranque.

A renovação é outra troca. Quando a chave de uma associação filha é renovada, os pares podem realizar uma nova troca de chaves com o grupo indicado nas suas propostas, e esse é o primeiro momento em que as definições do grupo são comparadas. Por isso dois pares em desacordo podem autenticar-se, instalar uma associação filha e passar tráfego, e depois falhar na renovação.

Onde se esconde a incompatibilidade na cadeia da proposta

No strongSwan o grupo é acrescentado à proposta filha, e é por isso que uma cadeia como aes256gcm16-prfsha256-ecp256 parece uma escolha de cifra mas também transporta um requisito de troca de chaves. Um par que só oferece aes256gcm16-prfsha256 não tem esse requisito, e as duas listas cruzam-se na cifra mas divergem na troca.

Leia a proposta filha e a proposta IKE como listas separadas. Um grupo que aparece na lista IKE não diz nada sobre a lista filha, e editar uma enquanto se lê a outra é a forma habitual de isto passar despercebido.

Leia a falha, não o ficheiro que editou

Encontre o notify que terminou a troca. Uma renovação de chave filha que devolve «nenhuma proposta aceitável» aponta para as listas de propostas; um pedido de renovação que nunca recebe resposta aponta para o caminho ou para um par que deixou de escutar. Estes dois exigem correções diferentes, e a redação da linha de registo separa-os.

Confirme a configuração em execução e não a que está no disco. Um ficheiro guardado mas não carregado, ou uma ligação relida a partir de outro include, produzirão uma incompatibilidade que nenhuma edição do ficheiro visível consegue corrigir.

Três eventos a que todos chamam renovação de chave

A renovação da chave da associação IKE, a reautenticação IKE e a renovação da chave da associação filha são operações separadas com regras de proposta separadas. Uma falha reportada numa delas não diz nada diretamente sobre as outras, e um registo que as mistura lê-se como uma única avaria recorrente quando são três.

Repare em que evento o par fala, e verifique depois as propostas apenas para esse evento. Altere uma lista, recarregue e force o mesmo evento outra vez. Se o registo nomear uma reautenticação, a proposta IKE é a que deve ser lida. Se nomear uma renovação de chave filha, a proposta filha transporta o grupo que importa.

Desligar a renovação não é uma correção

Pôr o tempo de renovação de chave a zero suprime a troca que falha, e o túnel sobrevive depois até ser desmontado ou o par reiniciar. O que comprou foi uma chave mais duradoura e uma incompatibilidade que o voltará a encontrar durante uma migração, uma auditoria ou uma atualização do fornecedor. O mesmo se aplica a tempos de vida esticados muito para além da política que o outro lado espera.

Alinhe antes as propostas. Escolha um grupo que ambos os pares implementem, coloque-o na proposta filha nas duas pontas, e mantenha a política de renovação dentro do intervalo que a organização realmente exige.

Prove-o com a troca que falhou

Encurte o tempo de renovação de chave filha numa janela de manutenção para que o evento chegue em minutos em vez de horas, ou dispare uma renovação manual. Depois vigie uma renovação bem-sucedida e confirme que o tráfego continua a passar por ela, porque um novo handshake que instala uma associação filha mas deixa cair o fluxo da aplicação é outro defeito.

Depois restaure o tempo de vida normal e guarde os dois registos de eventos, o falhado e o bem-sucedido. A prova que quer é que a ligação sobrevive ao seu próprio ciclo de vida, não que sobreviveu a um ping.