FortiGate Azure-nøkkelutskifting: peer SA-forslaget samsvarer ikke med den lokale policyen
En fungerende IKEv2-tunnel kan likevel avvise erstatnings-CHILD SA. Sammenlign forslaget som fornyelsen faktisk forhandler om, ikke det den første ping brukte.
Tunnelen kom opp, trafikken fløt, og senere sier loggen peer SA proposal not match local policy. De fleste leser den linjen som bevis for at de to konfigurasjonene aldri samsvarte. Vanligvis betyr den noe snevrere: de samsvarte for den første CHILD SA og sluttet å samsvare ved den første fornyelsen, fordi den første assosiasjonen aldri trengte utvekslingen som de senere utfører. Den forskjellen avgjør hvor du skal se.
Den første CHILD SA arver, de senere forhandler
I IKEv2 opprettes den første CHILD SA under IKE_AUTH, og nøklene utledes fra nøkkelmaterialet til IKE SA. På det tidspunktet finnes det ingen egen Diffie-Hellman-utveksling, så en PFS-gruppe som den ene peer ikke kan godta, blir rett og slett ikke prøvd ennå. Tunnelen ser sunn ut fordi kravet du senere vil feile på, aldri ble testet.
En CHILD_SA-nøkkelutskifting er en annen meldingssekvens. Når PFS er konfigurert, kjører peerne en ny nøkkelutveksling og må bli enige om en gruppe begge sider godtar, i tillegg til ESP-forslaget for den nye assosiasjonen. Det er øyeblikket avviket blir synlig, og derfor navngir feilen et forslag i stedet for en rute.
Så «det virket i går» forteller deg ingenting om forslaget. Det forteller deg at den første utvekslingen lyktes, noe du allerede visste.
Les den mislykkede utvekslingen, ikke den første ping
Samle den vellykkede IKE-autentiseringen, den første CHILD SA og den mislykkede erstatningen fra begge ender før du endrer noe. Navngi deretter operasjonen presist: IKE SA-nøkkelutskifting, IKE-reautentisering og CHILD SA-nøkkelutskifting er tre forskjellige hendelser, og «fase 2» dekker dem alle i dagligtale.
Sammenlign feltene nedenfor for forbindelsen som feilet, ikke for tunnelen generelt.
| Lag | Verdier å sammenligne |
|---|---|
| IKE | Versjon, kryptering og integritet eller PRF-oppsett, DH-gruppe |
| IPsec / CHILD | ESP-kryptering og -integritet, tiltenkt PFS- eller nøkkelutvekslingsgruppe |
| Beskyttet trafikk | Lokale og eksterne selektorer, plus enhver policybasert selektorinnstilling |
På FortiGate åpner du fase-2-forslaget, PFS-innstillingen og de godkjente DH-gruppene for den tunnelen. Les de innleste verdiene i stedet for å utlede dem fra en forbindelse som ble opprettet tidligere. Et skjermbilde av GUI-siden er svakere bevis enn den kjørende konfigurasjonen, fordi de to kan være uenige etter en oppgradering. Eksporter seksjonen du endret, og ta vare på den sammen med saken.
Azures standardpolicy er fortsatt en policy
At det ikke er knyttet en egendefinert policy til forbindelsen, betyr ikke at Azure ikke bruker noen. Forbindelsen faller tilbake på gatewayens standardforslagssett, som kan være bredere eller smalere enn det FortiGate-en din tilbyr. Hvis de to settene overlapper for IKE, men ikke for ESP med PFS, får du nøyaktig dette feilmønsteret.
Denne skrivebeskyttede visningen viser policyen som faktisk er knyttet, uten å lekke hemmeligheter:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesBruk de virkelige ressursnavnene dine. Når en eksplisitt policy er nødvendig, setter du den på forbindelsesressursen. Den er ikke en bryter for hele gatewayen, og den gjelder ikke i det stille for andre tunneler på samme gateway.
I portalen er siden Configuration for den forbindelsen stedet der en egendefinert IPsec/IKE-policy hører hjemme. Microsofts veiledning for egendefinerte policyer lister opp de støttede parameterne og SKU-kravene. Azure tar én fullstendig kombinasjon per forbindelse, så du angir IKE-feltene og IPsec-feltene sammen, ikke ett om gangen.
PFS er et krav, ikke en bryter å vippe
Hvis sikkerhetsgrunnlinjen din krever PFS, er løsningen en gruppe som begge peerne godtar på begge sider, uttrykt gjennom en samsvarende policy. Å slå av PFS for å få feilen til å forsvinne endrer sikkerhetsegenskapen du prøvde å beholde, og den dukker vanligvis opp igjen senere som et annet avvik.
En Azure-spesifikk felle: når du velger GCM for ESP, må krypterings- og integritetsvalgene navngi samme GCM-algoritme og samme nøkkellengde. Å blande en GCM-chiffer med en separat integritetsalgoritme gir en kombinasjon tjenesten avviser, og det ser ut som et peer-avvik til du leser policyen nøye.
Velg den sterkeste kombinasjonen begge ender støtter og kravet ditt tillater, og skriv den deretter i endringsloggen. Neste person vil sammenligne med den loggen, ikke med minnet om en fungerende tunnel. Ta med PFS-gruppen og ESP-forslaget, ikke bare policynavnet. Når noen senere spør hvorfor en revisjon feilet eller hvorfor en nøkkelutskifting er treg, svarer den linjen på begge spørsmålene.
Verifiser utvekslingen som feilet
Planlegg endringen med en gjenopprettingsvei, fordi redigering av policyen kan avbryte tunnelen du prøver å reparere. Når trafikken er tilbake, vent på eller utløs en CHILD_SA-fornyelse og bekreft at den nye assosiasjonen etableres med den tiltenkte PFS-gruppen. Bekreft deretter at applikasjonstrafikk fortsetter gjennom den.
To villspor er verdt å navngi. SA-levetider er lokale spesifikasjoner, så ulike verdier er normale, og å endre dem flytter bare når problemet dukker opp. DPD oppdager om en peer er i live; å heve tidsgrensen bringer ikke ESP- eller PFS-valg i samsvar.
Registrer det forhandlede resultatet og neste hendelse etter endringen. Hvis forbindelsen nå feiler før IKE-autentiseringen er fullført, ser du på IKE-innstillingene du nettopp redigerte, ikke på den opprinnelige CHILD-fornyelsesfeilen.