O que entra numa proposta IPsec? Campos de IKE e ESP

O IKE arranca, ambos os pares anunciam AES, e o túnel falha na mesma com NO_PROPOSAL_CHOSEN. O registo nomeia a proposta mas não o campo que não correspondeu. Uma proposta é uma oferta completa, e um único campo incompatível invalida toda a combinação em vez de apenas aquela linha. Lê-la como um saco de escolhas independentes de algoritmos é a razão habitual pela qual o desajuste permanece invisível.

Duas negociações com listas de propostas separadas

O IKEv2 constrói duas associações de segurança. A primeira é a IKE SA, que protege a própria troca de controlo, e a segunda é a CHILD SA, que transporta o seu tráfego através do ESP. Cada uma tem a sua própria lista de propostas, e um par pode aceitar uma e rejeitar a outra.

Essa separação explica uma confusão comum: uma IKE SA funcional prova apenas que os algoritmos do canal de controlo corresponderam. Se a proposta CHILD falhar, o túnel não transporta um único pacote, mesmo que a primeira fase esteja concluída e os registos pareçam saudáveis no topo.

A ordem dentro de cada lista também conta. O respondedor escolhe entre as ofertas ordenadas do iniciador, pelo que mover uma entrada amplamente compatível para cima de uma estreita muda o conjunto instalado sem alterar um único nome de algoritmo. Fixe essa ordem na configuração em vez de confiar nos valores predefinidos. Uma ordem estável torna também a comparação de registos entre locais significativa.

Que campos pertencem a que proposta

O conjunto de campos é pequeno, mas não é idêntico nas duas negociações. Leia a tabela linha a linha, porque um campo de uma coluna pode faltar na outra. A sintaxe varia consoante a implementação; a documentação de propostas do strongSwan é uma referência concreta.

O campo de cifragem nomeia o cifrador e, na maioria das sintaxes, o comprimento da chave. O campo de integridade nomeia o hash usado para autenticar o texto cifrado, e o PRF nomeia a função que deriva material de chave para a IKE SA. O grupo DH estabelece material secreto partilhado novo, e é por isso que aparece dos dois lados mas com finalidades diferentes.

Os números de sequência estendidos pertencem apenas ao caminho de dados. Alargam o espaço de sequência e são negociados como parte da proposta CHILD, pelo que um desajuste aí rejeita uma oferta CHILD deixando a IKE SA intacta.

Como uma oferta completa é selecionada

Cada proposta é um conjunto, e o respondedor procura um conjunto em que cada campo obrigatório seja aceitável. Duas listas podem conter ambas AES e SHA-256 e ainda assim não terem nenhuma entrada compatível, porque o comprimento da chave, o PRF ou o grupo DH diferem. A comparação ocorre por proposta, não por algoritmo.

Quando nada corresponde, o respondedor envia NO_PROPOSAL_CHOSEN com o tipo de SA que falhou. Leia a que lista de propostas a notificação se refere antes de editar a configuração; alterar os algoritmos ESP quando a proposta IKE foi rejeitada desperdiça um ciclo de depuração.

Vale a pena conhecer o comportamento de seleção quando ajusta um perfil. Algumas implementações preferem a ordem do iniciador, outras reordenam segundo a política local, por isso um conjunto que funciona entre dois fornecedores pode desaparecer quando inverte o lado que inicia a ligação.

O AEAD remove um campo em vez de acrescentar um

AES-GCM e ChaCha20-Poly1305 autenticam e cifram numa só operação. Quando um deles é selecionado para o ESP, o algoritmo de integridade não é negociado em separado, porque a construção AEAD já o cobre. Uma proposta que junta AES-GCM a SHA-256 é, portanto, redundante no melhor caso e rejeitada no pior.

O PRF continua separado do lado do IKE, uma vez que deriva chaves para o canal de controlo em vez de proteger as cargas úteis. É por isso que uma proposta IKE pode legitimamente combinar um cifrador AEAD com um PRF e um grupo DH, enquanto a proposta ESP correspondente lista apenas o cifrador AEAD e o grupo PFS opcional.

O comprimento da chave faz parte do token de cifragem, pelo que AES-128-GCM e AES-256-GCM são ofertas diferentes. Um perfil copiado de um guia que assumia chaves de 256-bit não corresponderá a um ponto terminal configurado para 128-bit, embora ambas as linhas digam AES-GCM. Dois pares podem concordar quanto à família de cifradores e ainda assim rejeitar-se mutuamente por causa do número depois do hífen.

Leia a SA instalada, não a configuração

A lista de propostas configurada é uma oferta; a SA instalada é o resultado. No strongSwan e num kernel Linux, ambas as vistas estão disponíveis:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas imprime os algoritmos negociados por SA, incluindo se o CHILD usa AEAD. ip xfrm state mostra o que o kernel instalou realmente, e é aí que se confirma que uma renovação de chaves não recuou para um conjunto diferente do que documentou.

Guarde essa saída junto à configuração após uma correção. Quando uma atualização do cliente altera os valores predefinidos, o conjunto registado dá-lhe uma linha de base para comparar, e a comparação aponta o campo que se deslocou em vez de reiniciar a investigação desde o início.