FortiGate Azure і абнаўленне ключоў: прапанова peer SA не адпавядае лакальнай палітыцы
Працоўны тунель IKEv2 можа ўсё ж адхіліць замену CHILD SA. Параўнайце прапанову, якую фактычна ўзгадняе абнаўленне, а не тую, якую выкарыстаў першы ping.
Тунель падняўся, трафік пайшоў, а потым у часопісе з’яўляецца 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” у звычайнай размове ахоплівае ўсе.
Параўнайце палі ніжэй для злучэння, якое правалілася, а не для тунеля наогул.
| Узровень | Значэнні для параўнання |
|---|---|
| IKE | Версія, шыфраванне і цэласнасць або схема PRF, група DH |
| IPsec / CHILD | Шыфраванне і цэласнасць ESP, меркаваная група PFS або абмену ключамі |
| Абаронены трафік | Лакальныя і аддаленыя селектары, а таксама любая налада селектара на аснове палітыкі |
На 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.