Cifrados de Windows y strongSwan: acierte con la capa correcta

Ambos extremos dicen AES-128 y el túnel sigue negándose a construirse. CBC y GCM son transformaciones distintas que casualmente comparten una longitud de clave, y un cliente que ofrece una no satisface a una pasarela que solo acepta la otra. La palabra AES describe una familia, no un acuerdo.

También hay un segundo eje, y es el que produce los errores confusos.

Dos capas, dos listas independientes

IKE protege la propia negociación, mientras que la asociación hija protege el tráfico que realmente le importa. Windows expone la primera como método de cifrado y método de integridad, y la segunda como constantes de transformación de cifrado y autenticación. Esos campos no son alias entre sí, y un valor válido en uno puede ser carente de sentido o erróneo en el otro. Leer el perfil con esa división en mente elimina la mayor parte de la confusión.

La consecuencia práctica es que puede tener una política de intercambio de claves perfectamente aceptable y una política de canal de datos que el par no aceptará. Una lista negocia; la otra protege paquetes. Cambiar un valor en la primera no tiene ningún efecto sobre la segunda, por muy parecidas que se vean ambas en un diálogo de configuración.

Anote ambas listas antes de compararlas con la pasarela. Una comparación hecha de memoria es la forma de que un campo se edite dos veces y el otro nunca. Mantenga la consola de la pasarela abierta junto al perfil.

Lea el error junto a las propuestas

La etapa que falló le dice qué lista examinar. Un rechazo durante el intercambio inicial de claves es un problema de propuesta IKE, y ocurre antes de que exista cualquier asociación hija. Un fallo mientras se negocia la asociación de tráfico protegido es un problema de propuesta ESP, y el intercambio de claves ya ha tenido éxito. Un mensaje genérico de coincidencia de política del cliente no nombra ninguna de las dos etapas, por eso la visión propia de la pasarela es la útil.

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

Compare la propuesta recibida, la propuesta configurada y la seleccionada para ese único intento. Aquí importan tres listas distintas, y solo la última describe lo que realmente se usó. Cítela literalmente en el tique en lugar de resumirla.

Mantenga CBC y GCM como alternativas separadas

Una pasarela a la que se permite deliberadamente aceptar cualquiera de las dos familias necesita dos propuestas, no una. En strongSwan una coma separa alternativas y un guion une los componentes de un solo conjunto. Combinar ambas familias con guiones produce una propuesta imposible en lugar de dos aceptables.

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

La primera alternativa lleva cifrado autenticado y aún nombra una función seudoaleatoria, porque la derivación de claves necesita una incluso cuando la integridad procede del cifrado. La segunda alternativa es cifrado clásico con un algoritmo de integridad separado. Ambas siguen sujetas a lo que admita la implementación criptográfica cargada.

Una propuesta ESP no es una propuesta IKE renombrada

El token de cifrado parece idéntico en ambas listas, y casi nada más se traslada. Una propuesta ESP no tiene función seudoaleatoria de intercambio de claves, y sus requisitos de integridad y de secreto futuro se argumentan contra la política de Windows del otro lado en lugar de copiarse de la línea IKE. Traducir mecánicamente una lista a la otra produce algo que valida y nunca negocia.

Elija una dirección y manténgala. O la pasarela conserva una política solo GCM y el cliente despliega una política compatible completa, o la pasarela acepta ambas familias y el cliente conserva su conjunto existente. Habilitar un respaldo que la política de seguridad prohíbe no es una solución, por rápido que despeje el error.

Verifique ambos conjuntos y luego una renovación de claves

Confirme por separado el conjunto de intercambio de claves seleccionado y el conjunto de tráfico seleccionado, porque proceden de listas distintas y pueden tener éxito de forma independiente. Luego deje que ocurra una renovación de claves y confírmela también. Un primer apretón de manos que funciona y una renovación de claves que falla describen un conjunto de propuestas solo parcialmente aceptable.

Conserve esa evidencia junto con el cambio. Una desconexión recurrente necesita su propio registro de intercambio fallido antes de que alguien culpe a un temporizador o a un defecto de la plataforma.