FortiGate Azure-ny nøgle: peer SA-forslag matcher ikke den lokale politik
En fungerende IKEv2-tunnel kan stadig afvise CHILD SA-erstatningen. Sammenlign det forslag, som fornyelsen faktisk forhandler, ikke det det første ping brugte.
Tunnelen kom op, trafikken flød, og senere står der i loggen peer SA proposal not match local policy. De fleste læser den linje som bevis for, at de to konfigurationer aldrig har passet sammen. Normalt betyder den noget snævrere: de passede til den første CHILD SA og holdt op med at passe ved den første fornyelse, fordi den første association aldrig havde brug for den udveksling, som de senere udfører. Den forskel afgør, hvor du skal kigge.
Den første CHILD SA arver, de senere forhandler
I IKEv2 oprettes den første CHILD SA under IKE_AUTH, og dens nøgler udledes af IKE SA'ens nøglemateriale. Der er ingen selvstændig Diffie-Hellman-udveksling på det tidspunkt, så en PFS-gruppe, som den ene peer ikke kan acceptere, bliver ganske enkelt ikke prøvet endnu. Tunnelen ser sund ud, fordi det krav, du senere vil fejle på, aldrig blev testet.
En CHILD_SA-ny nøgle er en anden meddelelsesrækkefølge. Når PFS er konfigureret, kører peerne en frisk nøgleudveksling og skal blive enige om en gruppe, som begge sider accepterer, plus ESP-forslaget til den nye association. Det er det øjeblik, uoverensstemmelsen bliver synlig, og derfor navngiver fejlen et forslag i stedet for en rute.
Så “det virkede i går” fortæller dig intet om forslaget. Det fortæller dig, at den første udveksling lykkedes, hvilket du allerede vidste.
Læs den mislykkede udveksling, ikke det første ping
Indsaml den vellykkede IKE-godkendelse, den første CHILD SA og den mislykkede erstatning fra begge ender, før du ændrer noget. Navngiv derefter operationen præcist: IKE SA-ny nøgle, IKE-genautentificering og CHILD SA-ny nøgle er tre forskellige hændelser, og “fase 2” dækker dem alle i daglig tale.
Sammenlign felterne nedenfor for den forbindelse, der fejlede, ikke for tunnelen generelt.
| Lag | Værdier at sammenligne |
|---|---|
| IKE | Version, kryptering og integritet eller PRF-arrangement, DH-gruppe |
| IPsec / CHILD | ESP-kryptering og -integritet, den tilsigtede PFS- eller nøgleudvekslingsgruppe |
| Beskyttet trafik | Lokale og fjernede selektorer plus enhver politikbaseret selektorindstilling |
På FortiGate åbner du fase-2-forslaget, PFS-indstillingen og de accepterede DH-grupper for den tunnel. Læs de indlæste værdier i stedet for at udlede dem af en forbindelse, der blev oprettet tidligere. Et skærmbillede af GUI-siden er svagere bevis end den kørende konfiguration, fordi de to kan være uenige efter en opgradering. Eksportér det afsnit, du ændrede, og gem det sammen med billetten.
Azures standardpolitik er stadig en politik
At der ikke er knyttet en brugerdefineret politik til forbindelsen, betyder ikke, at Azure ikke anvender nogen. Forbindelsen falder tilbage til gatewayens standardforslagssæt, som kan være bredere eller snævrere end det, din FortiGate tilbyder. Hvis de to sæt overlapper for IKE, men ikke for ESP med PFS, får du præcis dette fejlmønster.
Denne skrivebeskyttede visning viser den politik, der faktisk er knyttet, uden at afsløre hemmeligheder:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesBrug dine rigtige ressourcenavne. Når en eksplicit politik er nødvendig, skal du angive den på forbindelsesressourcen. Det er ikke en kontaktskifter for hele gatewayen, og den gælder ikke i det stille for andre tunneler på samme gateway.
I portalen er Configuration-siden for den forbindelse stedet, hvor en brugerdefineret IPsec/IKE-politik hører til. Microsofts guide til brugerdefinerede politikker viser de understøttede parametre og SKU-krav. Azure tager én komplet kombination pr. forbindelse, så du angiver IKE-felterne og IPsec-felterne sammen, ikke én ad gangen.
PFS er et krav, ikke en kontakt, man lige slår om
Hvis din sikkerhedsbaseline kræver PFS, er løsningen en gruppe, som begge peers accepterer på begge sider, udtrykt gennem en matchende politik. At slå PFS fra for at få fejlen til at forsvinde ændrer den sikkerhedsegenskab, du forsøgte at bevare, og den dukker normalt op igen senere som en anden uoverensstemmelse.
En Azure-specifik fælde: når du vælger GCM til ESP, skal krypterings- og integritetsvalgene navngive den samme GCM-algoritme og nøglelængde. At blande et GCM-chiffer med en separat integritetsalgoritme giver en kombination, som tjenesten afviser, og det ser ud som en peer-uoverensstemmelse, indtil du læser politikken grundigt.
Vælg den stærkeste kombination, som begge ender understøtter, og som dit krav tillader, og skriv den derefter i ændringsregistret. Den næste person vil sammenligne med det register, ikke med en erindring om en fungerende tunnel. Skriv PFS-gruppen og ESP-forslaget i det, ikke bare politiknavnet. Når nogen senere spørger, hvorfor en revision fejlede, eller hvorfor en ny nøgle er langsom, svarer den linje på begge spørgsmål.
Bekræft den udveksling, der fejlede
Planlæg ændringen med en gendannelsesvej, fordi redigering af politikken kan afbryde den tunnel, du prøver at rette. Når trafikken vender tilbage, vent på eller udløs en CHILD_SA-fornyelse, og bekræft, at den nye association er oprettet med den tilsigtede PFS-gruppe. Bekræft derefter, at applikationstrafik fortsætter igennem den.
To vildspor er værd at navngive. SA-levetider er lokale specifikationer, så ulige værdier er normale, og at ændre dem flytter kun, hvornår problemet viser sig. DPD registrerer, om en peer er i live; at hæve dens timeout bringer ikke ESP- eller PFS-valg i overensstemmelse.
Registrér det forhandlede resultat og den næste hændelse efter ændringen. Hvis forbindelsen nu fejler, før IKE-godkendelsen er fuldført, kigger du på de IKE-indstillinger, du netop har redigeret, ikke på den oprindelige CHILD-fornyelsesfejl.