IKEv2 en Windows e FortiGate: tres axustes que a xente fusiona
O intercambio de claves IKE, a protección da CHILD SA e a autenticación do par son tres filas separadas. Coincidir os números de grupo en dous diálogos non as fusiona.
Un acordo IKEv2 entre un cliente Windows e unha pasarela FortiGate segue fallando, e a busca dun número que non coincide produce unha lista de números aínda máis longa. A lista só se volve manexable cando se divide en tres filas que fallan de forma independente: o intercambio de claves que protexe IKE, a protección aplicada á CHILD SA e a autenticación que demostra quen é cada parte. Os números de grupo aparecen en dúas desas filas e significan cousas distintas.
Tres filas que fallan de forma independente
A primeira fila é o intercambio de claves dentro do propio IKE, que xera as claves que protexen a negociación. A segunda é a proposta para a CHILD SA, que protexe o tráfico que transporta o túnel. A terceira é a autenticación, que decide que presenta cada parte e como o valida a outra.
Os fallos prodúcense en lugares distintos. Un fallo de intercambio detén a negociación antes de que exista ningún túnel. Un fallo da CHILD SA ocorre despois de que a autenticación teña éxito, ás veces só nunha renovación de claves. Un fallo de autenticación pode parecer un fallo de intercambio nos rexistros se só se le o primeiro erro.
Separar as filas non é contabilidade. Cambia que axuste paga a pena cambiar e evita o movemento máis caro de todo este ámbito, que é rexenerar certificados que funcionan para arranxar unha discrepancia de proposta. Que unha fila cambie nunca debería obrigar ás outras dúas a cambiar con ela. Esa independencia é todo o sentido de escribilas por separado.
Que controlan os dous campos de Windows
Windows mantén dous campos separados: DHGroup configura o propio intercambio IKE, mentres que PfsGroup configura a política IPsec que protexe o tráfico do túnel. Pertencen a fases distintas. Comparar un campo IKE de Windows cun valor de fase 2 de FortiGate proba a parella equivocada, e os números poden coincidir mentres o intercambio subxacente segue fallando.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAO segundo e o terceiro comando informan das asociacións de seguridade que existen realmente, que é o máis parecido a unha resposta que un cliente pode darlle. Unha asociación de modo principal sen unha asociación de modo rápido é un problema da CHILD SA, e é a sinatura dunha discrepancia de fase 2 máis que dun problema de certificado.
Anote que se ofreceu e que se seleccionou nun intento. Unha lista ofrecida que contén unha proposta aceptable e unha proposta seleccionada que non coincide coa política da pasarela é un desacordo de configuración, non un misterio de interoperabilidade.
| 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 non escolle a súa clave de sinatura
A inferencia errónea máis persistente neste ámbito é que escoller un grupo DH de curva elíptica require un certificado de curva elíptica. Un grupo DH proporciona material para o intercambio de claves; o algoritmo de sinatura négócao o marco de autenticación, e son dúas decisións separadas en IKEv2.
RFC 7427 existe precisamente porque esas decisións antes estaban entrelazadas, e define como se anuncian e se escollen os algoritmos de sinatura con independencia do intercambio de claves. Unha pasarela pode admitir á vez un grupo de curva e unha selección de esquemas de sinatura.
Así que cando unha negociación falla tras un cambio de grupo, mire o método de autenticación antes de mirar o tipo de clave do certificado. Cambiar un certificado é unha operación lenta e arriscada que raramente é a resposta, e facelo primeiro destrúe a súa capacidade de saber que cambio axudou de verdade. Lea a fila de autenticación antes de tocar o almacén de certificados.
Manteña os dous en filas separadas da folla de acordo e o erro deixará de ser tentador. Unha fila enumera grupos, a outra enumera esquemas de sinatura e identidades, e ningunha é evidencia sobre a outra.
Pon cada clave privada co seu propietario real
Unha pasarela que presenta o seu propio certificado necesita a clave privada que lle corresponde. Un par que valida unha cadea necesita o certificado da CA e, en concreto, non necesita a clave de sinatura da CA. Confundir eses tres artefactos é como a xente acaba importando unha clave privada de CA nun dispositivo VPN para facer que un certificado apareza noutra categoría.
En FortiOS os papeis son distintos: un certificado local coa súa clave, un certificado remoto usado para identificar un par e unha entrada de CA remota que establece confianza nos certificados que esa CA asinou. Unha entrada de CA remota sen clave privada non está incompleta; é correcta para o seu propósito.
As claves de sinatura de CA importadas amplían a autoridade de calquera que poida ler ese dispositivo. Tampouco resolven a validación ordinaria do par, porque a validación necesita o certificado público e a decisión de confianza, non a capacidade de emitir certificados novos.
Manteña a clave de sinatura da CA co proceso do propio emisor e anote que dispositivo ten que clave. Unha táboa curta de propietarios vale máis que unha táboa máis longa de algoritmos cando unha auditoría pregunta quen podería suplantar a quen. Ninguén importa unha clave que sabe que é só de inventario. Escriba o inventario antes do incidente, non despois.