Ambos pares admiten AES, ambos aceptan SHA-256 y, aun así, el túnel no levanta. La propuesta falló en un componente que nadie comparó, normalmente el grupo de intercambio de claves. Esta guía lee el intercambio real antes de cambiar nada, aplica una sola política acotada y deja una reversión que restaura los parámetros anteriores.

Lea el fallo antes de cambiar un grupo

Un «error de coincidencia de política» es un resumen, no un diagnóstico. Significa que no se encontró ninguna propuesta aceptable para ambos y no dice nada sobre qué componente se rechazó. Trátelo como el inicio de la investigación y no como prueba sobre un grupo concreto.

La respuesta suele estar del lado del servidor. Un registro de strongSwan en un nivel adecuado enumera la propuesta que recibió del cliente y la propuesta que está configurado para aceptar, y la diferencia entre ambas listas nombra el componente que falló.

No suponga que el cliente ofrece lo que dice una publicación antigua del foro. El perfil activo y su política instalada deciden la lista ofrecida, y una compilación de Windows actualizada puede ofrecer un conjunto distinto del de la captura de pantalla que está copiando.

Escriba ambas listas. Cuatro posiciones de transformación y un grupo son una lista corta, y compararla línea por línea lleva menos tiempo que cualquier experimento. Cuatro posiciones se retienen con facilidad. Un archivo de registro no.

Compare cada transformación, no un solo nombre conocido

Una propuesta IKE es un conjunto de elecciones que deben coincidir todas. El cifrado protege la negociación, la integridad o un PRF la autentica, y un grupo Diffie-Hellman establece material de clave nuevo. Una propuesta que coincide en las dos primeras y difiere en la tercera sigue siendo inaceptable para ambos pares.

Los dos campos de Windows que aquí se confunden pertenecen a fases distintas. DHGroup se aplica al intercambio de claves IKE, mientras que PfsGroup se aplica a la asociación hija que protege el tráfico. Cambiar el segundo no puede reparar un fallo en el primero.

Los nombres de grupo difieren entre implementaciones, y eso es otra fuente de confusión. strongSwan escribe modp2048 y ecp256, mientras que Windows usa nombres de enumeración como Group14 y ECP256, así que una comparación tiene que traducir antes de comparar. Mantenga una nota de dos columnas con ambos nombres. La siguiente discrepancia se clasifica entonces en segundos.

TransformWindows parameterstrongSwan nameFailure it causes
EncryptionCipherTransformConstantsaes, aes256gcm and similarNo common proposal at all
Integrity or PRFAuthenticationTransformConstantssha256, sha512 and similarProposal rejected after encryption matches
Key-exchange groupDHGroupmodp2048, ecp256Exchange fails during key establishment
Child SA protectionPfsGroupesp proposal groupsTunnel negotiates, data association does not

Aplique una política completa y acotada

El instrumento admitido para un perfil IKEv2 nativo es una política IPsec por conexión, definida como un solo objeto en lugar de campo por campo. Previsualícela primero, aplíquela después y conserve los parámetros anteriores en el registro de cambios.

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

El conmutador -WhatIf previsualiza el cambio local y no aplica nada. Eso es útil y también es una trampa habitual, porque una previsualización solo demuestra que los parámetros son sintácticamente aceptables para el cmdlet local. No dice nada sobre si la puerta de enlace aceptará la propuesta resultante.

De paso, ajuste también el ámbito. Una conexión en el almacén de todos los usuarios necesita el parámetro correspondiente de todos los usuarios, y editar el perfil por usuario con el mismo nombre para mostrar cambia otro objeto que el túnel no usa.

Después ajuste el lado strongSwan al mismo conjunto antes de probar. Un cambio coordinado en ambos extremos es la única versión de esto que converge; cambiar un lado y reintentar una y otra vez produce un registro lleno del mismo rechazo.

Verifique el intercambio y la renovación de claves por separado

Una conexión correcta es una observación, y la renovación de claves es otra. La negociación IKE inicial usa un conjunto de parámetros, y la asociación hija que transporta el tráfico puede renegociarse más adelante con su propia política. Una instalación que conecta y luego cae al cabo de un rato suele ser el segundo caso.

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

El primer comando muestra la visión del servidor de las asociaciones establecidas, incluida la SA hija y su vida restante. El segundo muestra lo que el perfil del cliente tiene ahora, y es la única forma de confirmar que la política que definió es la política vigente.

Observe una renovación de claves completa antes de declarar el éxito. Eso significa dejar la conexión activa el tiempo suficiente para que se sustituya la asociación hija y luego confirmar que el tráfico continúa. La mayoría de las discrepancias de política se esconden en ese paso, porque la negociación inicial puede tener éxito con un conjunto que la renovación no acepta.

La reversión es el conjunto de parámetros anterior, no un repliegue permisivo. Si el cliente solo ofrecía un grupo antiguo y débil, la respuesta es mejorar la política común del cliente y el servidor, no añadir ese grupo a la puerta de enlace donde cualquier par futuro podrá negociar a la baja hasta él.

Anote los cuatro parámetros, el grupo, el ámbito de la conexión y el resultado de la renovación. Es una nota corta, y es la diferencia entre una guía y una historia sobre el día en que el túnel levantó.

Artículos relacionados