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.