FortiGate Azure rekey: la proposta de SA del peer no coincideix amb la política local
Un túnel IKEv2 que funciona pot rebutjar la substitució de la CHILD SA. Compareu la proposta que la renovació negocia realment, no la que va fer servir el primer ping.
El túnel va pujar, el trànsit va fluir i més tard el registre diu peer SA proposal not match local policy. La majoria de la gent llegeix aquesta línia com a prova que les dues configuracions mai no van coincidir. Normalment vol dir una cosa més estreta: van coincidir per a la primera CHILD SA i van deixar de coincidir a la primera renovació, perquè la primera associació mai no va necessitar l’intercanvi que fan les posteriors. Aquesta distinció decideix on has de mirar.
La primera CHILD SA hereta, les posteriors negocien
A IKEv2, la CHILD SA inicial es crea durant IKE_AUTH i les seves claus es deriven del material de clau de la IKE SA. En aquell moment no hi ha cap intercanvi de Diffie-Hellman separat, així que un grup PFS que un peer no pot acceptar simplement encara no es prova. El túnel sembla sa perquè el requisit que més endavant incompliràs mai no s’ha provat.
Una renovació de clau de CHILD_SA és una seqüència de missatges diferent. Quan PFS està configurat, els peers fan un intercanvi de claus nou i han d’acordar un grup que tots dos costats acceptin, a més de la proposta ESP per a la nova associació. Aquest és el moment en què la discrepància es fa visible, i és per això que l’error anomena una proposta i no una ruta.
Per tant, “ahir funcionava” no et diu res sobre la proposta. Et diu que l’intercanvi inicial va tenir èxit, cosa que ja sabies.
Llegeix l’intercanvi fallit, no el primer ping
Recull l’autenticació IKE correcta, la CHILD SA inicial i la substitució fallida dels dos extrems abans de canviar res. Després anomena l’operació amb precisió: la renovació de clau de la IKE SA, la reautenticació IKE i la renovació de clau de la CHILD SA són tres esdeveniments diferents, i “fase 2” els cobreix tots en una conversa informal.
Compareu els camps següents per a la connexió que va fallar, no per al túnel en general.
| Capa | Valors a comparar |
|---|---|
| IKE | Versió, xifratge i integritat o disposició PRF, grup DH |
| IPsec / CHILD | Xifratge i integritat ESP, grup PFS o d’intercanvi de claus previst |
| Trànsit protegit | Selectors locals i remots, més qualsevol paràmetre de selector basat en polítiques |
A FortiGate, obre la proposta de fase-2, el paràmetre PFS i els grups DH acceptats per a aquell túnel. Llegeix els valors carregats en lloc d’inferir-los d’una connexió que es va establir abans. Una captura de pantalla de la pàgina de la GUI és una prova més feble que la configuració en execució, perquè les dues poden discrepar després d’una actualització. Exporta la secció que has canviat i guarda-la amb el tiquet.
La política per defecte d’Azure continua sent una política
Que no hi hagi cap política personalitzada adjunta a la connexió no vol dir que Azure no n’apliqui cap. La connexió recorre al conjunt de propostes per defecte de la passarel·la, que pot ser més ampli o més estret que el que ofereix el teu FortiGate. Si els dos conjunts se superposen per a IKE però no per a ESP amb PFS, obtens exactament aquest patró de fallada.
Aquesta vista només de lectura mostra la política realment adjunta, sense abocar secrets:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesFeu servir els noms reals dels vostres recursos. Quan cal una política explícita, definiu-la al recurs de la connexió. No és un commutador de tota la passarel·la i no s’aplica silenciosament a altres túnels de la mateixa passarel·la.
Al portal, la pàgina Configuration d’aquesta connexió és on va una política IPsec/IKE personalitzada. La guia de Microsoft per a polítiques personalitzades llista els paràmetres admesos i els requisits de SKU. Azure pren una combinació completa per connexió, així que especifiqueu els camps IKE i els camps IPsec junts, no un a la vegada.
PFS és un requisit, no un commutador per girar
Si la vostra línia base de seguretat requereix PFS, la solució és un grup que tots dos peers acceptin als dos costats, expressat mitjançant una política coincident. Desactivar PFS per fer desaparèixer l’error canvia la propietat de seguretat que intentàveu mantenir, i normalment reapareix més tard com una discrepància diferent.
Un parany específic d’Azure: quan trieu GCM per a ESP, les seleccions de xifratge i integritat han de nomenar el mateix algorisme GCM i la mateixa longitud de clau. Barrejar un xifrador GCM amb un algorisme d’integritat separat produeix una combinació que el servei rebutja, i sembla una discrepància entre peers fins que llegiu la política amb atenció.
Trieu la combinació més forta que tots dos extrems admetin i que el vostre requisit permeti, i després escriviu-la al registre de canvis. La propera persona es compararà amb aquest registre, no amb el record d’un túnel que funcionava. Hi heu de posar el grup PFS i la proposta ESP, no només el nom de la política. Quan algú pregunti més tard per què ha fallat una auditoria o per què una renovació és lenta, aquella línia respon les dues preguntes.
Verifiqueu l’intercanvi que va fallar
Planifiqueu el canvi amb un camí de recuperació, perquè editar la política pot interrompre el túnel que intenteu arreglar. Quan torni el trànsit, espereu o forceu una renovació de CHILD_SA i confirmeu que la nova associació s’estableix amb el grup PFS previst. Després confirmeu que el trànsit d’aplicacions hi continua.
Val la pena nomenar dues pistes falses. Les durades de les SA són especificacions locals, així que valors desiguals són normals i canviar-los només mou quan apareix el problema. DPD detecta si un peer és viu; apujar-ne el temps d’espera no alinea les tries d’ESP ni de PFS.
Anoteu el resultat negociat i l’esdeveniment següent després del canvi. Si ara la connexió falla abans que es completi l’autenticació IKE, esteu mirant els paràmetres IKE que acabeu d’editar, no la fallada original de renovació de la CHILD.