IKEv2 en Windows y FortiGate: tres ajustes que la gente fusiona
El intercambio de claves IKE, la protección de la CHILD SA y la autenticación del par son tres filas separadas. Coincidir los números de grupo en dos diálogos no las fusiona.
Un acuerdo IKEv2 entre un cliente Windows y una puerta de enlace FortiGate sigue fallando, y la búsqueda de un número que no coincide produce una lista de números aún más larga. La lista solo se vuelve manejable cuando se divide en tres filas que fallan de forma independiente: el intercambio de claves que protege IKE, la protección aplicada a la CHILD SA y la autenticación que demuestra quién es cada parte. Los números de grupo aparecen en dos de esas filas y significan cosas distintas.
Tres filas que fallan de forma independiente
La primera fila es el intercambio de claves dentro del propio IKE, que genera las claves que protegen la negociación. La segunda es la propuesta para la CHILD SA, que protege el tráfico que transporta el túnel. La tercera es la autenticación, que decide qué presenta cada parte y cómo lo valida la otra.
Los fallos se producen en lugares distintos. Un fallo de intercambio detiene la negociación antes de que exista ningún túnel. Un fallo de la CHILD SA ocurre después de que la autenticación tenga éxito, a veces solo en una renovación de claves. Un fallo de autenticación puede parecer un fallo de intercambio en los registros si solo se lee el primer error.
Separar las filas no es contabilidad. Cambia qué ajuste merece la pena cambiar y evita el movimiento más caro de todo este ámbito, que es regenerar certificados que funcionan para arreglar una discrepancia de propuesta. Que una fila cambie nunca debería obligar a las otras dos a cambiar con ella. Esa independencia es todo el sentido de escribirlas por separado.
Qué controlan los dos campos de Windows
Windows mantiene dos campos separados: DHGroup configura el propio intercambio IKE, mientras que PfsGroup configura la política IPsec que protege el tráfico del túnel. Pertenecen a fases distintas. Comparar un campo IKE de Windows con un valor de fase 2 de FortiGate prueba la pareja equivocada, y los números pueden coincidir mientras el intercambio subyacente sigue fallando.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAEl segundo y el tercer comando informan de las asociaciones de seguridad que existen realmente, que es lo más parecido a una respuesta que un cliente puede darle. Una asociación de modo principal sin una asociación de modo rápido es un problema de la CHILD SA, y es la firma de una discrepancia de fase 2 más que de un problema de certificado.
Anote qué se ofreció y qué se seleccionó en un intento. Una lista ofrecida que contiene una propuesta aceptable y una propuesta seleccionada que no coincide con la política de la puerta de enlace es un desacuerdo de configuración, no un misterio de interoperabilidad.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Un grupo de curva elíptica no elige su clave de firma
La inferencia errónea más persistente en este ámbito es que elegir un grupo DH de curva elíptica requiere un certificado de curva elíptica. Un grupo DH proporciona material para el intercambio de claves; el algoritmo de firma lo negocia el marco de autenticación, y son dos decisiones separadas en IKEv2.
RFC 7427 existe precisamente porque esas decisiones antes estaban entrelazadas, y define cómo se anuncian y se eligen los algoritmos de firma con independencia del intercambio de claves. Una puerta de enlace puede admitir a la vez un grupo de curva y una selección de esquemas de firma.
Así que cuando una negociación falla tras un cambio de grupo, mire el método de autenticación antes de mirar el tipo de clave del certificado. Cambiar un certificado es una operación lenta y arriesgada que rara vez es la respuesta, y hacerlo primero destruye su capacidad de saber qué cambio ayudó de verdad. Lea la fila de autenticación antes de tocar el almacén de certificados.
Mantenga los dos en filas separadas de la hoja de acuerdo y el error dejará de ser tentador. Una fila enumera grupos, la otra enumera esquemas de firma e identidades, y ninguna es evidencia sobre la otra.
Ponga cada clave privada con su propietario real
Una puerta de enlace que presenta su propio certificado necesita la clave privada que le corresponde. Un par que valida una cadena necesita el certificado de la CA y, en concreto, no necesita la clave de firma de la CA. Confundir esos tres artefactos es como la gente acaba importando una clave privada de CA en un dispositivo VPN para hacer que un certificado aparezca en otra categoría.
En FortiOS los roles son distintos: un certificado local con su clave, un certificado remoto usado para identificar a un par y una entrada de CA remota que establece confianza en los certificados que esa CA firmó. Una entrada de CA remota sin clave privada no está incompleta; es correcta para su propósito.
Las claves de firma de CA importadas amplían la autoridad de cualquiera que pueda leer ese dispositivo. Tampoco resuelven la validación ordinaria del par, porque la validación necesita el certificado público y la decisión de confianza, no la capacidad de emitir certificados nuevos.
Mantenga la clave de firma de la CA con el proceso del propio emisor y anote qué dispositivo tiene qué clave. Una tabla corta de propietarios vale más que una tabla más larga de algoritmos cuando una auditoría pregunta quién podría suplantar a quién. Nadie importa una clave que sabe que es solo de inventario. Escriba el inventario antes del incidente, no después.