Cifras Windows e strongSwan: acerte a camada certa

Ambas as pontas dizem AES-128 e o túnel continua a recusar-se a ser estabelecido. CBC e GCM são transformações diferentes que por acaso partilham o mesmo comprimento de chave, e um cliente que oferece uma não satisfaz um gateway que só aceita a outra. A palavra AES descreve uma família, não um acordo.

Há também um segundo eixo, e é ele que produz os erros confusos.

Duas camadas, duas listas independentes

O IKE protege a própria negociação, enquanto a associação filha protege o tráfego que realmente lhe importa. O Windows expõe a primeira como método de cifragem e método de integridade, e a segunda como constantes de transformação de cifra e autenticação. Esses campos não são aliases um do outro, e um valor válido num pode ser sem sentido ou errado no outro. Ler o perfil com essa separação em mente elimina a maior parte da confusão.

A consequência prática é que pode ter uma política de troca de chaves perfeitamente aceitável e uma política de canal de dados que o par não aceitará. Uma lista negoceia; a outra protege pacotes. Alterar um valor na primeira não tem qualquer efeito sobre a segunda, por muito parecidas que as duas sejam numa caixa de diálogo de configuração.

Anote as duas listas antes de as comparar com o gateway. Uma comparação feita de memória é a forma de um campo ser editado duas vezes e o outro nunca. Mantenha a consola do gateway aberta ao lado do perfil.

Leia o erro ao lado das propostas

A fase que falhou diz-lhe que lista examinar. Uma recusa durante a troca de chaves inicial é um problema de proposta IKE, e acontece antes de existir qualquer associação filha. Uma falha enquanto a associação de tráfego protegido está a ser negociada é um problema de proposta ESP, e a troca de chaves já teve sucesso. Uma mensagem genérica de correspondência de política do cliente não nomeia nenhuma das fases, por isso a visão do próprio gateway é a útil.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Compare a proposta recebida, a proposta configurada e a selecionada para essa única tentativa. Três listas diferentes importam aqui, e só a última descreve o que foi realmente usado. Cite-a literalmente no ticket em vez de a resumir.

Mantenha CBC e GCM como alternativas separadas

Um gateway deliberadamente autorizado a aceitar qualquer das famílias precisa de duas propostas, não de uma. No strongSwan uma vírgula separa alternativas e um hífen une os componentes de um único conjunto. Combinar as duas famílias com hífenes produz uma proposta impossível em vez de duas aceitáveis.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

A primeira alternativa transporta cifragem autenticada e ainda nomeia uma função pseudoaleatória, porque a derivação de chaves precisa de uma mesmo quando a integridade vem da cifra. A segunda alternativa é cifragem clássica com um algoritmo de integridade separado. Ambas continuam sujeitas ao que a implementação criptográfica carregada suportar.

Uma proposta ESP não é uma proposta IKE renomeada

O token da cifra parece idêntico nas duas listas, e quase nada mais é transportado. Uma proposta ESP não tem função pseudoaleatória de troca de chaves, e os seus requisitos de integridade e de sigilo futuro são argumentados contra a política Windows do outro lado em vez de copiados da linha IKE. Traduzir mecanicamente uma lista na outra produz algo que valida e nunca negoceia.

Escolha uma direção e mantenha-se nela. Ou o gateway mantém uma política só GCM e o cliente implementa uma política compatível completa, ou o gateway aceita as duas famílias e o cliente mantém o conjunto existente. Ativar uma alternativa que a política de segurança proíbe não é uma correção, por mais depressa que limpe o erro.

Verifique os dois conjuntos e depois uma renovação de chaves

Confirme separadamente o conjunto de troca de chaves selecionado e o conjunto de tráfego selecionado, porque vêm de listas diferentes e podem ter sucesso de forma independente. Depois deixe ocorrer uma renovação de chaves e confirme-a também. Um primeiro aperto de mão que funciona e uma renovação de chaves que falha descrevem um conjunto de propostas apenas parcialmente aceitável.

Guarde essa evidência com a alteração. Uma desconexão recorrente precisa do seu próprio registo de troca falhada antes de alguém culpar um temporizador ou um defeito da plataforma.