FortiGate Azure ri-kyçje: propozimi peer SA nuk përputhet me politikën lokale

Tuneli u ngrit, trafiku rrjedhi dhe më vonë regjistri thotë peer SA proposal not match local policy. Shumica e njerëzve e lexojnë atë rresht si provë që dy konfigurimet nuk përputhën kurrë. Zakonisht do të thotë diçka më të ngushtë: u përputhën për CHILD SA e parë dhe pushuan së përputhuri në ri-përtëritjen e parë, sepse shoqërimi i parë nuk kishte nevojë kurrë për shkëmbimin që bëjnë të mëvonshmit. Pikërisht ky dallim vendos ku duhet të shikoni.

CHILD SA e parë trashëgon, të mëvonshmet negociojnë

Në IKEv2, CHILD SA fillestare krijohet gjatë IKE_AUTH dhe çelësat e saj nxirren nga materiali çelësor i IKE SA. Në atë moment nuk ka shkëmbim të veçantë Diffie-Hellman, kështu që një grup PFS që njëri peer nuk mund ta pranojë thjesht nuk testohet ende. Tuneli duket i shëndetshëm sepse kërkesa ku do të dështoni më vonë nuk u testua kurrë.

Një ri-kyçje CHILD_SA është një sekuencë tjetër mesazhesh. Kur PFS është konfiguruar, peer-ët kryejnë një shkëmbim të ri çelësash dhe duhet të bien dakord për një grup që pranojnë të dyja palët, plus propozimin ESP për shoqërimin e ri. Ai është momenti kur mospërputhja bëhet e dukshme, dhe për këtë arsye gabimi emërton një propozim dhe jo një rrugë.

Pra, “dje funksiononte” nuk ju thotë asgjë për propozimin. Ju thotë se shkëmbimi fillestar pati sukses, gjë që e dinit tashmë.

Lexoni shkëmbimin e dështuar, jo ping-un e parë

Përpara se të ndryshoni ndonjë gjë, mblidhni nga të dyja anët vërtetimin IKE të suksesshëm, CHILD SA fillestare dhe zëvendësimin e dështuar. Pastaj emërtoni veprimin me saktësi: ri-kyçja e IKE SA, ri-vërtetimi IKE dhe ri-kyçja e CHILD SA janë tre ngjarje të ndryshme, dhe “faza 2” në bisedën e përditshme i përfshin të gjitha.

Krahasoni fushat më poshtë për lidhjen që dështoi, jo për tunelin në përgjithësi.

Në FortiGate, hapni propozimin e fazës-2, rregullimin PFS dhe grupet DH të pranuara për atë tunel. Lexoni vlerat e ngarkuara në vend që t’i nxirrni nga një lidhje e vendosur më parë. Një pamje ekrani e faqes GUI është provë më e dobët se konfigurimi në punë, sepse të dyja mund të ndryshojnë pas një përditësimi. Eksportoni seksionin që ndryshuat dhe mbajeni me tiketin.

Politika e parazgjedhur e Azure mbetet një politikë

Mungesa e një politike të personalizuar të bashkangjitur lidhjes nuk do të thotë që Azure nuk zbaton asnjë. Lidhja kthehet te grupi i parazgjedhur i propozimeve të portës, i cili mund të jetë më i gjerë ose më i ngushtë se ai që ofron FortiGate-i juaj. Nëse të dy grupet mbivendosen për IKE, por jo për ESP me PFS, merrni pikërisht këtë model dështimi.

Kjo pamje vetëm-lexim tregon politikën e bashkangjitur në të vërtetë, pa zbuluar sekrete:

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

Përdorni emrat e vërtetë të burimeve tuaja. Kur nevojitet një politikë e qartë, vendoseni në burimin e lidhjes. Nuk është një çelës për të gjithë portën dhe nuk zbatohet në heshtje për tunelet e tjera në të njëjtën portë.

Në portal, faqja Configuration e asaj lidhjeje është vendi ku shkon një politikë IPsec/IKE e personalizuar. Udhëzuesi i Microsoft për politikat e personalizuara rendit parametrat e mbështetur dhe kërkesat e SKU-së. Azure merr një kombinim të plotë për lidhje, kështu që i specifikoni fushat IKE dhe fushat IPsec së bashku, jo një nga një.

PFS është një kërkesë, jo një çelës për t’u kthyer

Nëse vija juaj bazë e sigurisë kërkon PFS, zgjidhja është një grup që të dy peer-ët pranojnë në të dyja anët, i shprehur përmes një politike përputhëse. Fikja e PFS që gabimi të zhduket ndryshon vetinë e sigurisë që po përpiqeshit të mbanit, dhe zakonisht rikthehet më vonë si një mospërputhje tjetër.

Një grackë specifike për Azure: kur zgjidhni GCM për ESP, zgjedhjet e kriptimit dhe integritetit duhet të emërtojnë të njëjtin algoritëm GCM dhe të njëjtën gjatësi çelësi. Përzierja e një cifre GCM me një algoritëm të veçantë integriteti prodhon një kombinim që shërbimi e refuzon, dhe kjo duket si mospërputhje mes peer-ëve derisa ta lexoni me kujdes politikën.

Zgjidhni kombinimin më të fortë që të dy skajet mbështesin dhe kërkesa juaj lejon, pastaj shkruajeni në regjistrin e ndryshimeve. Personi tjetër do të krahasojë me atë regjistër, jo me kujtimin e një tuneli funksional. Vendosni në të grupin PFS dhe propozimin ESP, jo vetëm emrin e politikës. Kur dikush më vonë pyet pse dështoi një auditim ose pse një ri-kyçje është e ngadaltë, ai rresht u përgjigjet të dyja pyetjeve.

Verifikoni shkëmbimin që dështoi

Planifikojeni ndryshimin me një rrugë rikuperimi, sepse redaktimi i politikës mund të ndërpresë tunelin që po përpiqeni të rregulloni. Pasi trafiku të kthehet, prisni ose shkaktoni një ri-përtëritje CHILD_SA dhe konfirmoni që shoqërimi i ri vendoset me grupin PFS të synuar. Pastaj konfirmoni që trafiku i aplikacioneve vazhdon përmes tij.

Dy gjurmë të rreme ia vlen të përmenden. Jetëgjatësitë e SA janë specifikime lokale, prandaj vlerat e pabarabarta janë normale dhe ndryshimi i tyre thjesht zhvendos kur shfaqet problemi. DPD zbulon nëse një peer është i gjallë; rritja e afatit të tij nuk i rreshton zgjedhjet ESP ose PFS.

Regjistroni rezultatin e negociuar dhe ngjarjen pasardhëse pas ndryshimit. Nëse lidhja tani dështon përpara se të përfundojë vërtetimi IKE, po shikoni rregullimet IKE që sapo redaktuat, jo dështimin origjinal të ri-përtëritjes CHILD.