FortiGate Azure rekey: a proposta de SA do peer non coincide coa política local
Un túnel IKEv2 que funciona pode rexeitar aínda a CHILD SA de substitución. Compare a proposta que negocia de verdade a renovación, non a que usou o primeiro ping.
O túnel subiu, o tráfico fluiu e máis tarde o rexistro di peer SA proposal not match local policy. A maioría da xente le esa liña como proba de que as dúas configuracións nunca coincidiron. Normalmente significa algo máis concreto: coincidiron para a primeira CHILD SA e deixaron de coincidir na primeira renovación, porque a primeira asociación nunca necesitou o intercambio que fan as posteriores. Esa distinción decide onde mirar.
A primeira CHILD SA herda, as posteriores negocian
En IKEv2, a CHILD SA inicial créase durante IKE_AUTH e as súas claves derívanse do material de claves da IKE SA. Nese momento non hai un intercambio Diffie-Hellman separado, así que un grupo PFS que un dos peers non pode aceptar simplemente aínda non se proba. O túnel parece san porque o requisito que máis adiante incumprirá nunca se probou.
Unha renovación de claves de CHILD_SA é unha secuencia de mensaxes distinta. Cando PFS está configurado, os peers executan un intercambio de claves novo e deben acordar un grupo que ambos os lados acepten, ademais da proposta ESP para a nova asociación. Ese é o momento en que a discrepancia se fai visible, e por iso o erro nomea unha proposta e non unha ruta.
Así que “onte funcionaba” non lle di nada sobre a proposta. Dille que o intercambio inicial tivo éxito, algo que xa sabía.
Lea o intercambio fallido, non o primeiro ping
Reúna a autenticación IKE correcta, a CHILD SA inicial e a substitución fallida de ambos os extremos antes de cambiar nada. Despois nomee a operación con precisión: a renovación de claves da IKE SA, a reautenticación IKE e a renovación de claves da CHILD SA son tres acontecementos distintos, e “fase 2” cóbreos todos nunha conversa informal.
Compare os campos seguintes para a conexión que fallou, non para o túnel en xeral.
| Capa | Valores que comparar |
|---|---|
| IKE | Versión, cifrado e integridade ou disposición de PRF, grupo DH |
| IPsec / CHILD | Cifrado e integridade de ESP, grupo PFS ou de intercambio de claves previsto |
| Tráfico protexido | Selectores locais e remotos, máis calquera axuste de selector baseado en políticas |
En FortiGate, abra a proposta de fase-2, o axuste de PFS e os grupos DH aceptados para ese túnel. Lea os valores cargados en lugar de inferilos dunha conexión que se estableceu antes. Unha captura da páxina da GUI é unha proba máis feble que a configuración en execución, porque ambas poden discrepar tras unha actualización. Exporte a sección que cambiou e gárdea co tícket.
A política predeterminada de Azure segue sendo unha política
Que non haxa unha política personalizada anexada á conexión non significa que Azure non aplique ningunha. A conexión recorre ao conxunto de propostas predeterminado da pasarela, que pode ser máis amplo ou máis estreito ca o que ofrece o seu FortiGate. Se os dous conxuntos se solapan para IKE pero non para ESP con PFS, obtén exactamente este patrón de fallo.
Esta vista de só lectura mostra a política realmente anexada, sen verter segredos:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesUse os nomes reais dos seus recursos. Cando se necesita unha política explícita, defínaa no recurso da conexión. Non é un interruptor de toda a pasarela e non se aplica en silencio a outros túneles da mesma pasarela.
No portal, a páxina Configuration desa conexión é onde vai unha política IPsec/IKE personalizada. A guía de Microsoft sobre políticas personalizadas enumera os parámetros admitidos e os requisitos de SKU. Azure toma unha combinación completa por conexión, así que especifica os campos de IKE e os de IPsec xuntos, non un de cada vez.
PFS é un requisito, non un interruptor que xirar
Se a súa liña base de seguridade esixe PFS, a solución é un grupo que ambos os peers acepten nos dous lados, expresado mediante unha política coincidente. Desactivar PFS para que o erro desapareza cambia a propiedade de seguridade que intentaba conservar, e normalmente reaparece máis tarde como outra discrepancia.
Unha trampa específica de Azure: cando escolle GCM para ESP, as seleccións de cifrado e integridade deben nomear o mesmo algoritmo GCM e a mesma lonxitude de clave. Mesturar un cifrador GCM cun algoritmo de integridade separado produce unha combinación que o servizo rexeita, e parece unha discrepancia entre peers ata que le a política con atención.
Escolla a combinación máis forte que ambos os extremos admitan e que o seu requisito permita, e despois anótea no rexistro de cambios. A seguinte persoa comparará con ese rexistro, non co recordo dun túnel que funcionaba. Inclúa o grupo PFS e a proposta ESP, non só o nome da política. Cando alguén pregunte máis tarde por que fallou unha auditoría ou por que unha renovación é lenta, esa liña responde a ambas as preguntas.
Verifique o intercambio que fallou
Planifique o cambio cunha vía de recuperación, porque editar a política pode interromper o túnel que intenta arranxar. Cando volva o tráfico, espere ou provoque unha renovación de CHILD_SA e confirme que a nova asociación se establece co grupo PFS previsto. Despois confirme que o tráfico de aplicacións segue pasando por ela.
Paga a pena nomear dúas pistas falsas. As duracións das SA son especificacións locais, así que os valores desiguais son normais e cambialos só move cando aparece o problema. DPD detecta se un peer está vivo; subir o seu tempo de espera non aliña as eleccións de ESP nin de PFS.
Rexiste o resultado negociado e o seguinte acontecemento despois do cambio. Se agora a conexión falla antes de que se complete a autenticación IKE, está mirando os axustes de IKE que acaba de editar, non o fallo orixinal de renovación da CHILD.