Cifrados de Windows e strongSwan: acerte coa capa correcta

Ambos os extremos din AES-128 e o túnel segue negándose a construírse. CBC e GCM son transformacións distintas que casualmente comparten unha lonxitude de clave, e un cliente que ofrece unha non satisfai unha pasarela que só acepta a outra. A palabra AES describe unha familia, non un acordo.

Tamén hai un segundo eixo, e é o que produce os erros confusos.

Dúas capas, dúas listas independentes

IKE protexe a propia negociación, mentres que a asociación filla protexe o tráfico que realmente lle importa. Windows expón a primeira como método de cifrado e método de integridade, e a segunda como constantes de transformación de cifrado e autenticación. Eses campos non son alias entre si, e un valor válido nun pode carecer de sentido ou ser erróneo no outro. Ler o perfil con esa división en mente elimina a maior parte da confusión.

A consecuencia práctica é que pode ter unha política de intercambio de claves perfectamente aceptable e unha política de canle de datos que o par non aceptará. Unha lista negocia; a outra protexe paquetes. Cambiar un valor na primeira non ten ningún efecto sobre a segunda, por moi parecidas que se vexan ambas nun diálogo de configuración.

Anote ambas as listas antes de comparalas coa pasarela. Unha comparación feita de memoria é a forma de que un campo se edite dúas veces e o outro nunca. Manteña a consola da pasarela aberta xunto ao perfil.

Lea o erro xunto ás propostas

A etapa que fallou dille que lista examinar. Un rexeitamento durante o intercambio inicial de claves é un problema de proposta IKE, e ocorre antes de que exista calquera asociación filla. Un fallo mentres se negocia a asociación de tráfico protexido é un problema de proposta ESP, e o intercambio de claves xa tivo éxito. Unha mensaxe xenérica de coincidencia de política do cliente non nomea ningunha das dúas etapas, por iso a visión propia da pasarela é a útil.

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

Compare a proposta recibida, a proposta configurada e a seleccionada para ese único intento. Aquí importan tres listas distintas, e só a última describe o que realmente se usou. Cíteo literalmente no tícket en lugar de resumilo.

Manteña CBC e GCM como alternativas separadas

Unha pasarela á que se permite deliberadamente aceptar calquera das dúas familias necesita dúas propostas, non unha. En strongSwan unha coma separa alternativas e un guión une os compoñentes dun só conxunto. Combinar ambas as familias con guións produce unha proposta imposible en lugar de dúas aceptables.

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

A primeira alternativa leva cifrado autenticado e aínda nomea unha función pseudoaleatoria, porque a derivación de claves necesita unha mesmo cando a integridade vén do cifrado. A segunda alternativa é cifrado clásico cun algoritmo de integridade separado. Ambas seguen suxeitas ao que admita a implementación criptográfica cargada.

Unha proposta ESP non é unha proposta IKE renomeada

O token de cifrado parece idéntico en ambas as listas, e case nada máis se traslada. Unha proposta ESP non ten función pseudoaleatoria de intercambio de claves, e os seus requisitos de integridade e de segredo futuro arguméntanse contra a política de Windows do outro lado en lugar de copiarse da liña IKE. Traducir mecanicamente unha lista á outra produce algo que valida e nunca negocia.

Escolla unha dirección e mantéñase nela. Ou a pasarela conserva unha política só GCM e o cliente despregar unha política compatible completa, ou a pasarela acepta ambas as familias e o cliente conserva o seu conxunto existente. Habilitar un respaldo que a política de seguridade prohibe non é unha solución, por rápido que despexe o erro.

Verifique ambos os conxuntos e logo unha renovación de claves

Confirme por separado o conxunto de intercambio de claves seleccionado e o conxunto de tráfico seleccionado, porque proceden de listas distintas e poden ter éxito de forma independente. Logo deixe que ocorra unha renovación de claves e confírmaa tamén. Un primeiro aperto de mans que funciona e unha renovación de claves que falla describen un conxunto de propostas só parcialmente aceptable.

Conserve esa evidencia xunto co cambio. Unha desconexión recorrente necesita o seu propio rexistro de intercambio fallido antes de que alguén culpe un temporizador ou un defecto da plataforma.