Tunelis pakilo, srautas ėjo, o vėliau žurnale rašoma peer SA proposal not match local policy. Dauguma žmonių šią eilutę skaito kaip įrodymą, kad dvi konfigūracijos niekada nesutapo. Paprastai tai reiškia ką nors siauresnio: jos sutapo pirmajam CHILD SA ir nustojo sutapti pirmojo atnaujinimo metu, nes pirmoji asociacija niekada nereikėjo tų mainų, kuriuos atlieka vėlesnės. Būtent šis skirtumas lemia, kur ieškoti.

Pirmasis CHILD SA paveldi, vėlesni derasi

IKEv2 pradinis CHILD SA sukuriamas IKE_AUTH metu, o jo raktai išvedami iš IKE SA raktinės medžiagos. Tuo metu nėra atskirų Diffie-Hellman mainų, todėl PFS grupė, kurios vienas peer negali priimti, tiesiog dar netikrinama. Tunelis atrodo sveikas, nes reikalavimas, kurio vėliau nepavyks įvykdyti, niekada nebuvo išbandytas.

CHILD_SA rakto atnaujinimas yra kita pranešimų seka. Kai PFS sukonfigūruotas, peerai atlieka naujus raktų mainus ir turi susitarti dėl grupės, kurią priima abi pusės, taip pat dėl naujos asociacijos ESP pasiūlymo. Būtent tuo metu neatitikimas tampa matomas, ir todėl klaida įvardija pasiūlymą, o ne maršrutą.

Taigi „vakar tai veikė“ nieko nepasako apie pasiūlymą. Tai pasako, kad pradiniai mainai pavyko, ką jau žinojote.

Skaitykite nepavykusius mainus, o ne pirmąjį ping

Prieš ką nors keisdami surinkite iš abiejų pusių sėkmingą IKE autentifikaciją, pradinį CHILD SA ir nepavykusį pakeitimą. Tada tiksliai įvardykite operaciją: IKE SA rakto atnaujinimas, IKE pakartotinė autentifikacija ir CHILD SA rakto atnaujinimas yra trys skirtingi įvykiai, o „2 fazė“ kasdieniame pokalbyje apima juos visus.

Palyginkite toliau nurodytus laukus nepavykusiai jungčiai, o ne tuneliui apskritai.

SluoksnisLygintinos reikšmės
IKEVersija, šifravimas ir vientisumas arba PRF išdėstymas, DH grupė
IPsec / CHILDESP šifravimas ir vientisumas, numatyta PFS arba raktų mainų grupė
Apsaugotas srautasVietiniai ir nuotoliniai selektoriai, taip pat bet koks politikos pagrindu veikiantis selektoriaus nustatymas

FortiGate atidarykite to tunelio 2 fazės pasiūlymą, PFS nustatymą ir priimtas DH grupes. Skaitykite įkeltas reikšmes, o ne spėkite jas iš anksčiau nustatytos jungties. GUI puslapio ekrano kopija yra silpnesnis įrodymas nei veikianti konfigūracija, nes po atnaujinimo abi gali skirtis. Eksportuokite pakeistą skyrių ir saugokite jį su bilietu.

Azure numatytoji politika vis tiek yra politika

Tai, kad prie jungties nepridėta jokia pasirinktinė politika, nereiškia, kad Azure jos netaiko. Jungtis grįžta prie šliuzo numatytojo pasiūlymų rinkinio, kuris gali būti platesnis arba siauresnis nei tai, ką siūlo jūsų FortiGate. Jei abu rinkiniai persidengia IKE atžvilgiu, bet ne ESP su PFS atžvilgiu, gausite būtent tokį gedimo modelį.

Ši tik skaitymo peržiūra rodo faktiškai pridėtą politiką, neatskleisdama paslapčių:

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

Naudokite tikrus savo išteklių pavadinimus. Kai reikia aiškios politikos, nustatykite ją jungties ištekliui. Tai ne viso šliuzo jungiklis ir ji tyliai netaikoma kitiems to paties šliuzo tuneliams.

Portale Configuration puslapis yra vieta, kur dedama pasirinktinė IPsec/IKE politika. Microsoft pasirinktinių politikų vadovas išvardija palaikomus parametrus ir SKU reikalavimus. Azure ima vieną visą derinį vienai jungčiai, todėl IKE laukus ir IPsec laukus nurodote kartu, o ne po vieną.

PFS yra reikalavimas, o ne jungiklis, kurį reikia perjungti

Jei jūsų saugumo bazinė linija reikalauja PFS, sprendimas yra grupė, kurią abu peerai priima abiejose pusėse, išreikšta atitinkančia politika. PFS išjungimas, kad klaida išnyktų, pakeičia saugumo savybę, kurią bandėte išlaikyti, ir ji paprastai vėliau grįžta kaip kitas neatitikimas.

Vienas Azure būdingas spąstas: kai ESP pasirenkate GCM, šifravimo ir vientisumo pasirinkimai turi nurodyti tą patį GCM algoritmą ir tą patį rakto ilgį. GCM šifro maišymas su atskiru vientisumo algoritmu sukuria derinį, kurį paslauga atmeta, ir tai atrodo kaip peerų neatitikimas, kol atidžiai neperskaitysite politikos.

Pasirinkite stipriausią derinį, kurį palaiko abu galai ir leidžia jūsų reikalavimas, tada užrašykite jį pakeitimų žurnale. Kitas žmogus lygins su tuo žurnalu, o ne su prisiminimu apie veikusį tunelį. Įrašykite PFS grupę ir ESP pasiūlymą, o ne tik politikos pavadinimą. Kai vėliau kas nors paklaus, kodėl auditas nepavyko ar kodėl rakto atnaujinimas lėtas, ta eilutė atsakys į abu klausimus.

Patikrinkite nepavykusius mainus

Suplanuokite pakeitimą su atkūrimo keliu, nes politikos redagavimas gali nutraukti tunelį, kurį bandote sutvarkyti. Kai srautas grįš, palaukite CHILD_SA atnaujinimo arba jį suaktyvinkite ir patvirtinkite, kad nauja asociacija nustatyta su numatyta PFS grupe. Tada patvirtinkite, kad programų srautas ja teka toliau.

Du klaidingus pėdsakus verta įvardyti. SA gyvavimo trukmės yra vietinės specifikacijos, todėl nevienodos reikšmės yra normalios, o jų keitimas tik perkelia, kada problema pasirodys. DPD nustato, ar peer gyvas; jo laiko limito padidinimas nesuderina ESP ar PFS pasirinkimų.

Užfiksuokite suderėtą rezultatą ir kitą įvykį po pakeitimo. Jei jungtis dabar nepavyksta prieš pasibaigiant IKE autentifikacijai, žiūrite į ką tik redaguotus IKE nustatymus, o ne į pradinį CHILD atnaujinimo gedimą.

Susiję straipsniai