FortiGate Azure-nøkkelutskifting: peer SA-framlegget passar ikkje med den lokale policyen

Tunnelen kom opp, trafikken flaut, og seinare seier loggen peer SA proposal not match local policy. Dei fleste les den lina som prov for at dei to konfigurasjonane aldri samsvara. Vanlegvis tyder ho noko snevrare: dei samsvara for den første CHILD SA og slutta å samsvare ved den første fornyinga, fordi den første assosiasjonen aldri trong utvekslinga som dei seinare gjer. Den skilnaden avgjer kvar du skal sjå.

Den første CHILD SA arvar, dei seinare forhandlar

I IKEv2 vert den første CHILD SA oppretta under IKE_AUTH, og nøklane vert utleia frå nøkkelmaterialet til IKE SA. På det tidspunktet finst det inga eiga Diffie-Hellman-utveksling, så ei PFS-gruppe som den eine peer ikkje kan godta, vert rett og slett ikkje prøvd enno. Tunnelen ser sunn ut fordi kravet du seinare vil feile på, aldri vart testa.

Ei CHILD_SA-nøkkelutskifting er ein annan meldingssekvens. Når PFS er konfigurert, køyrer peera ei ny nøkkelutveksling og må bli samde om ei gruppe begge sider godtek, i tillegg til ESP-framlegget for den nye assosiasjonen. Det er augneblinken avviket vert synleg, og difor namngir feilen eit framlegg i staden for ei rute.

Så «det virka i går» fortel deg ingenting om framlegget. Det fortel deg at den første utvekslinga lukkast, noko du alt visste.

Les den mislukka utvekslinga, ikkje den første ping

Samle den vellukka IKE-autentiseringa, den første CHILD SA og den mislukka erstatninga frå begge endar før du endrar noko. Namngi deretter operasjonen presist: IKE SA-nøkkelutskifting, IKE-reautentisering og CHILD SA-nøkkelutskifting er tre ulike hendingar, og «fase 2» dekkjer dei alle i daglegtale.

Samanlikn felta nedanfor for sambandet som feila, ikkje for tunnelen generelt.

På FortiGate opnar du fase-2-framlegget, PFS-innstillinga og dei godkjende DH-gruppene for den tunnelen. Les dei innlaste verdiane i staden for å utleie dei frå eit samband som vart oppretta tidlegare. Eit skjermbilete av GUI-sida er svakare prov enn den køyrande konfigurasjonen, fordi dei to kan vere usamde etter ei oppgradering. Eksporter delen du endra, og ta vare på han saman med saka.

Standardpolicyen til Azure er framleis ein policy

At det ikkje er knytt ein eigendefinert policy til sambandet, tyder ikkje at Azure ikkje brukar nokon. Sambandet fell tilbake på standardframleggssettet til gatewayen, som kan vere breiare eller smalare enn det FortiGate-en din tilbyr. Viss dei to setta overlappar for IKE, men ikkje for ESP med PFS, får du nøyaktig dette feilmønsteret.

Denne skriveverna visinga syner policyen som faktisk er knytt, utan å leke hemmelegheiter:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Bruk dei verkelege ressursnamna dine. Når ein eksplisitt policy er naudsynt, set han på sambandsressursen. Han er ikkje ein brytar for heile gatewayen, og han gjeld ikkje i det stille for andre tunnelar på same gateway.

I portalen er sida Configuration for det sambandet staden der ein eigendefinert IPsec/IKE-policy høyrer heime. Rettleiinga til Microsoft for eigendefinerte policyar listar opp dei støtta parametrane og SKU-krava. Azure tek éin fullstendig kombinasjon per samband, så du oppgir IKE-felta og IPsec-felta saman, ikkje eitt om gongen.

PFS er eit krav, ikkje ein brytar å vippe

Viss tryggingsgrunnlina di krev PFS, er løysinga ei gruppe som begge peera godtek på begge sider, uttrykt gjennom ein samsvarande policy. Å slå av PFS for å få feilen til å forsvinne endrar tryggingseigenskapen du prøvde å behalde, og han dukkar vanlegvis opp att seinare som eit anna avvik.

Ei Azure-spesifikk felle: når du vel GCM for ESP, må krypterings- og integritetsvala namngi same GCM-algoritme og same nøkkellengd. Å blande ein GCM-chiffer med ein separat integritetsalgoritme gjev ein kombinasjon tenesta avviser, og det ser ut som eit peer-avvik til du les policyen nøye.

Vel den sterkaste kombinasjonen begge endar støttar og kravet ditt tillèt, og skriv han deretter i endringsloggen. Neste person vil samanlikne med den loggen, ikkje med minnet om ein fungerande tunnel. Ta med PFS-gruppa og ESP-framlegget, ikkje berre policynamnet. Når nokon seinare spør kvifor ein revisjon feila eller kvifor ei nøkkelutskifting er treg, svarar den lina på båe spørsmåla.

Stadfest utvekslinga som feila

Planlegg endringa med ein gjenopprettingsveg, fordi redigering av policyen kan bryte tunnelen du prøver å reparere. Når trafikken er tilbake, vent på eller utløys ei CHILD_SA-fornying og stadfest at den nye assosiasjonen vert oppretta med den tiltenkte PFS-gruppa. Stadfest deretter at applikasjonstrafikk held fram gjennom han.

To villspor er verd å namngi. SA-levetider er lokale spesifikasjonar, så ulike verdiar er normale, og å endre dei flyttar berre når problemet dukkar opp. DPD oppdagar om ein peer er i live; å heve tidsgrensa bringar ikkje ESP- eller PFS-val i samsvar.

Registrer det forhandla resultatet og neste hending etter endringa. Viss sambandet no feilar før IKE-autentiseringa er fullført, ser du på IKE-innstillingane du nettopp redigerte, ikkje på den opphavlege CHILD-fornyingsfeilen.