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.