FortiGate Azure-nyckelbyte: peer SA-förslaget matchar inte den lokala policyn
En fungerande IKEv2-tunnel kan ändå avvisa ersättnings-CHILD SA. Jämför det förslag som förnyelsen faktiskt förhandlar om, inte det som den första ping använde.
Tunneln kom upp, trafiken flöt och senare säger loggen peer SA proposal not match local policy. De flesta läser den raden som bevis för att de två konfigurationerna aldrig stämde överens. Oftast betyder den något snävare: de stämde för den första CHILD SA och slutade stämma vid den första förnyelsen, eftersom den första associationen aldrig behövde det utbyte som de senare gör. Den skillnaden avgör var du ska titta.
Den första CHILD SA ärver, de senare förhandlar
I IKEv2 skapas den första CHILD SA under IKE_AUTH och dess nycklar härleds från IKE SA:s nyckelmaterial. Vid den tidpunkten finns inget separat Diffie-Hellman-utbyte, så en PFS-grupp som den ena peeren inte kan acceptera testas helt enkelt inte än. Tunneln ser frisk ut eftersom kravet du senare kommer att fallera på aldrig testades.
Ett CHILD_SA-nyckelbyte är en annan meddelandesekvens. När PFS är konfigurerat kör peerarna ett nytt nyckelutbyte och måste enas om en grupp som båda sidor accepterar, plus ESP-förslaget för den nya associationen. Det är ögonblicket då avvikelsen blir synlig, och därför namnger felet ett förslag i stället för en rutt.
Så ”det fungerade igår” säger ingenting om förslaget. Det säger att det första utbytet lyckades, vilket du redan visste.
Läs det misslyckade utbytet, inte den första ping
Samla den lyckade IKE-autentiseringen, den första CHILD SA och den misslyckade ersättningen från båda ändar innan du ändrar något. Namnge sedan operationen exakt: IKE SA-nyckelbyte, IKE-omautentisering och CHILD SA-nyckelbyte är tre olika händelser, och ”fas 2” täcker dem alla i vardagligt tal.
Jämför fälten nedan för anslutningen som misslyckades, inte för tunneln i allmänhet.
| Lager | Värden att jämföra |
|---|---|
| IKE | Version, kryptering och integritet eller PRF-uppsättning, DH-grupp |
| IPsec / CHILD | ESP-kryptering och -integritet, avsedd PFS- eller nyckelutbytesgrupp |
| Skyddad trafik | Lokala och avlägsna selektorer, plus alla policybaserade selektorinställningar |
På FortiGate öppnar du fas-2-förslaget, PFS-inställningen och de accepterade DH-grupperna för den tunneln. Läs de inlästa värdena i stället för att härleda dem från en anslutning som upprättades tidigare. En skärmbild av GUI-sidan är svagare bevis än den körande konfigurationen, eftersom de två kan gå isär efter en uppgradering. Exportera avsnittet du ändrade och spara det med ärendet.
Azures standardpolicy är fortfarande en policy
Att ingen anpassad policy är kopplad till anslutningen betyder inte att Azure inte tillämpar någon. Anslutningen faller tillbaka på gatewayens standardset av förslag, som kan vara bredare eller smalare än det din FortiGate erbjuder. Om de två seten överlappar för IKE men inte för ESP med PFS, får du exakt det här felmönstret.
Den här skrivskyddade vyn visar policyn som faktiskt är kopplad, utan att läcka hemligheter:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesAnvänd dina riktiga resursnamn. När en uttrycklig policy behövs, ange den på anslutningsresursen. Det är inte en brytare för hela gatewayen, och den gäller inte tyst för andra tunnlar på samma gateway.
I portalen är sidan Configuration för den anslutningen platsen där en anpassad IPsec/IKE-policy hör hemma. Microsofts vägledning för anpassade policyer listar de parametrar som stöds och SKU-kraven. Azure tar en fullständig kombination per anslutning, så du anger IKE-fälten och IPsec-fälten tillsammans, inte ett i taget.
PFS är ett krav, inte en brytare att vippa
Om din säkerhetsbaslinje kräver PFS är lösningen en grupp som båda peerarna accepterar på båda sidor, uttryckt genom en matchande policy. Att stänga av PFS så att felet försvinner ändrar den säkerhetsegenskap du försökte behålla, och den dyker oftast upp igen senare som en annan avvikelse.
En Azure-specifik fälla: när du väljer GCM för ESP måste krypterings- och integritetsvalen ange samma GCM-algoritm och samma nyckellängd. Att blanda ett GCM-chiffer med en separat integritetsalgoritm ger en kombination som tjänsten avvisar, och det ser ut som en avvikelse mellan peerar tills du läser policyn noga.
Välj den starkaste kombination som båda ändar stöder och ditt krav tillåter, och skriv sedan ner den i ändringsloggen. Nästa person kommer att jämföra med den loggen, inte med minnet av en fungerande tunnel. Ta med PFS-gruppen och ESP-förslaget, inte bara policyns namn. När någon senare frågar varför en granskning misslyckades eller varför ett nyckelbyte är långsamt, svarar den raden på båda frågorna.
Verifiera utbytet som misslyckades
Planera ändringen med en återställningsväg, eftersom redigering av policyn kan avbryta tunneln du försöker reparera. När trafiken är tillbaka, vänta på eller utlös en CHILD_SA-förnyelse och bekräfta att den nya associationen upprättas med den avsedda PFS-gruppen. Bekräfta sedan att applikationstrafik fortsätter genom den.
Två villospår är värda att namnge. SA-livstider är lokala specifikationer, så olika värden är normala och att ändra dem flyttar bara när problemet dyker upp. DPD upptäcker om en peer lever; att höja dess tidsgräns jämkar inte ESP- eller PFS-val.
Registrera det förhandlade resultatet och nästa händelse efter ändringen. Om anslutningen nu misslyckas innan IKE-autentiseringen är klar tittar du på IKE-inställningarna du just redigerade, inte på det ursprungliga CHILD-förnyelsefelet.