FortiGate Azure обнова кључа: предлог peer SA не одговара локалној политици

Тунел се подигао, саобраћај је текао, а касније у дневнику пише peer SA proposal not match local policy. Већина људи тај ред чита као доказ да се две конфигурације никада нису поклопиле. Обично значи нешто уже: поклопиле су се за прву CHILD SA и престале да се поклапају при првој обнови, јер прва асоцијација никада није захтевала размену коју изводе касније. Управо та разлика одређује где да тражите.

Прва CHILD SA наслеђује, касније преговарају

У IKEv2 почетна CHILD SA се ствара током IKE_AUTH, а њени кључеви се изводе из кључног материјала IKE SA. У том тренутку нема посебне Diffie-Hellman размене, па се PFS група коју један peer не може да прихвати једноставно још не проверава. Тунел изгледа здраво јер захтев на ком ћете касније пасти никада није тестиран.

Обнова кључа CHILD_SA је други низ порука. Када је PFS конфигурисан, peer-ови обављају нову размену кључева и морају да се договоре о групи коју прихватају обе стране, плус предлог ESP за нову асоцијацију. То је тренутак када несагласност постаје видљива, и зато грешка именује предлог, а не руту.

Дакле „јуче је радило“ не говори вам ништа о предлогу. Говори да је почетна размена успела, што сте већ знали.

Читајте неуспелу размену, не први ping

Пре него што било шта промените, прикупите са обе стране успешну IKE аутентикацију, почетну CHILD SA и неуспелу замену. Затим прецизно именујте операцију: обнова кључа IKE SA, поновна аутентикација IKE и обнова кључа CHILD SA су три различита догађаја, а „фаза 2“ у свакодневном говору обухвата све њих.

Упоредите поља испод за везу која није успела, не за тунел уопште.

На FortiGate отворите предлог за фазу-2, подешавање PFS и прихваћене DH групе за тај тунел. Читајте учитане вредности уместо да их изводите из везе која је успостављена раније. Снимак екрана GUI странице је слабији доказ од конфигурације која ради, јер се њих две могу разићи после надградње. Извезите одељак који сте изменили и чувајте га са тикетом.

Подразумевана политика Azure је и даље политика

То што нема приложене прилагођене политике на вези не значи да Azure не примењује ниједну. Веза се враћа на подразумевани скуп предлога мрежног пролаза, који може бити шири или ужи од онога што нуди ваш FortiGate. Ако се два скупа преклапају за IKE, али не за ESP са PFS, добијате тачно овај образац неуспеха.

Овај приказ само за читање показује политику која је стварно приложена, без откривања тајни:

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

Користите стварна имена својих ресурса. Када је потребна изричита политика, поставите је на ресурсу везе. То није прекидач за цео пролаз и не примењује се тихо на друге тунеле на истом пролазу.

На порталу, страница Configuration те везе је место где иде прилагођена IPsec/IKE политика. Водич Microsoft-а за прилагођене политике наводи подржане параметре и захтеве за SKU. Azure узима једну потпуну комбинацију по вези, па поља IKE и поља IPsec наводите заједно, а не једно по једно.

PFS је захтев, а не прекидач који се преврће

Ако ваша безбедносна основна линија захтева PFS, решење је група коју прихватају оба peer-а са обе стране, изражена кроз одговарајућу политику. Искључивање PFS-а да грешка нестане мења безбедносно својство које сте покушавали да сачувате, и оно се обично касније враћа као друга несагласност.

Једна замка специфична за Azure: када изаберете GCM за ESP, избори шифровања и интегритета морају да наведу исти GCM алгоритам и исту дужину кључа. Мешање GCM шифре са посебним алгоритмом интегритета даје комбинацију коју услуга одбија, и то изгледа као несагласност међу peer-овима док пажљиво не прочитате политику.

Изаберите најјачу комбинацију коју подржавају оба краја и коју ваше правило дозвољава, а затим је запишите у евиденцију промена. Следећа особа ће се поредити са том евиденцијом, не са сећањем на тунел који је радио. Унесите у њу PFS групу и ESP предлог, не само назив политике. Када неко касније пита зашто је ревизија пропала или зашто је обнова кључа спора, тај ред одговара на оба питања.

Проверите размену која није успела

Планирајте промену са путом за опоравак, јер измена политике може прекинути тунел који покушавате да поправите. Када се саобраћај врати, сачекајте или покрените обнову CHILD_SA и потврдите да је нова асоцијација успостављена са предвиђеном PFS групом. Затим потврдите да се саобраћај апликација наставља кроз њу.

Два лажна трага вреди именовати. Животни век SA су локалне спецификације, па су неједнаке вредности нормалне и њихова промена само помера када се проблем појављује. DPD открива да ли је peer жив; повећање његовог временског ограничења не усклађује изборе ESP или PFS.

Забележите договорени резултат и следећи догађај после промене. Ако веза сада не успева пре него што се IKE аутентикација заврши, гледате у IKE подешавања која сте управо изменили, а не у првобитни неуспех обнове CHILD.