FortiGate Azure a obnova klíčů: návrh peer SA neodpovídá místní zásadě
Funkční tunel IKEv2 může přesto odmítnout náhradní CHILD SA. Porovnejte návrh, který obnova skutečně vyjednává, ne ten, který použil první ping.
Tunel se zvedl, provoz tekl a později v logu stojí peer SA proposal not match local policy. Většina lidí čte tento řádek jako důkaz, že se obě konfigurace nikdy neshodovaly. Obvykle to znamená něco užšího: shodovaly se pro první CHILD SA a při první obnově se shodovat přestaly, protože první asociace nikdy nepotřebovala výměnu, kterou provádějí ty následující. Právě tento rozdíl určuje, kam se dívat.
První CHILD SA dědí, další vyjednávají
V IKEv2 se počáteční CHILD SA vytváří během IKE_AUTH a její klíče se odvozují z klíčového materiálu IKE SA. V tom okamžiku neprobíhá samostatná výměna Diffie-Hellman, takže skupina PFS, kterou jeden peer nemůže přijmout, se zatím prostě nezkouší. Tunel vypadá zdravě, protože požadavek, na kterém později selžete, nebyl nikdy otestován.
Obnova klíče CHILD_SA je jiná posloupnost zpráv. Když je nakonfigurováno PFS, peery provedou novou výměnu klíčů a musí se dohodnout na skupině, kterou obě strany přijmou, plus na návrhu ESP pro novou asociaci. To je okamžik, kdy se neshoda stane viditelnou, a proto chyba jmenuje návrh, a ne trasu.
Takže „včera to fungovalo“ vám o návrhu neříká nic. Říká vám, že počáteční výměna uspěla, což jste už věděli.
Čtěte neúspěšnou výměnu, ne první ping
Než cokoli změníte, shromážděte úspěšnou autentizaci IKE, počáteční CHILD SA a neúspěšnou náhradu z obou stran. Pak operaci pojmenujte přesně: obnova klíče IKE SA, opakovaná autentizace IKE a obnova klíče CHILD SA jsou tři různé události a „fáze 2“ v běžné řeči zahrnuje všechny.
Porovnejte pole níže pro spojení, které selhalo, ne pro tunel obecně.
| Vrstva | Hodnoty k porovnání |
|---|---|
| IKE | Verze, šifrování a integrita nebo uspořádání PRF, skupina DH |
| IPsec / CHILD | Šifrování a integrita ESP, zamýšlená skupina PFS nebo výměny klíčů |
| Chráněný provoz | Místní a vzdálené selektory plus jakékoli nastavení selektoru založené na zásadách |
Na FortiGate otevřete návrh fáze-2, nastavení PFS a přijaté skupiny DH pro daný tunel. Čtěte načtené hodnoty, místo abyste je odvozovali ze spojení, které se navázalo dříve. Snímek obrazovky stránky GUI je slabší důkaz než běžící konfigurace, protože ty dvě se po upgradu mohou rozejít. Exportujte sekci, kterou jste změnili, a uložte ji k tiketu.
Výchozí zásada Azure je pořád zásada
To, že ke spojení není připojena žádná vlastní zásada, neznamená, že Azure žádnou neuplatňuje. Spojení se vrací k výchozí sadě návrhů brány, která může být širší nebo užší než to, co nabízí váš FortiGate. Pokud se obě sady překrývají pro IKE, ale ne pro ESP s PFS, dostanete přesně tento vzorec selhání.
Tento náhled jen pro čtení ukazuje skutečně připojenou zásadu, aniž by vyzrazoval tajemství:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesPoužijte skutečné názvy svých prostředků. Když je potřeba výslovná zásada, nastavte ji na prostředku spojení. Není to přepínač pro celou bránu a potichu se nevztahuje na jiné tunely na stejné bráně.
Na portálu je stránka Configuration tohoto spojení místem, kam patří vlastní zásada IPsec/IKE. Příručka Microsoftu pro vlastní zásady uvádí podporované parametry a požadavky na SKU. Azure bere jednu úplnou kombinaci na spojení, takže pole IKE a pole IPsec zadáváte společně, ne jedno po druhém.
PFS je požadavek, ne přepínač k přepnutí
Pokud vaše bezpečnostní základna vyžaduje PFS, řešením je skupina, kterou oba peery přijmou na obou stranách, vyjádřená odpovídající zásadou. Vypnutí PFS, aby chyba zmizela, mění bezpečnostní vlastnost, kterou jste se snažili zachovat, a obvykle se později vrátí jako jiná neshoda.
Jedna past specifická pro Azure: když pro ESP zvolíte GCM, volby šifrování a integrity musí uvádět stejný algoritmus GCM a stejnou délku klíče. Míchání šifry GCM se samostatným algoritmem integrity vytváří kombinaci, kterou služba odmítá, a to vypadá jako neshoda peerů, dokud zásadu pozorně nepřečtete.
Zvolte nejsilnější kombinaci, kterou oba konce podporují a kterou váš požadavek dovoluje, a zapište ji do záznamu o změnách. Další člověk ji bude porovnávat s tímto záznamem, ne se vzpomínkou na funkční tunel. Uveďte v něm skupinu PFS a návrh ESP, ne jen název zásady. Když se někdo později zeptá, proč audit selhal nebo proč je obnova pomalá, ten řádek odpoví na obě otázky.
Ověřte výměnu, která selhala
Naplánujte změnu s cestou obnovy, protože úprava zásady může přerušit tunel, který se snažíte opravit. Až se provoz vrátí, počkejte na obnovu CHILD_SA nebo ji vyvolejte a potvrďte, že nová asociace je navázána se zamýšlenou skupinou PFS. Poté potvrďte, že přes ni pokračuje provoz aplikací.
Dvě falešné stopy stojí za pojmenování. Životnosti SA jsou místní specifikace, takže nerovné hodnoty jsou normální a jejich změna jen posouvá, kdy se problém objeví. DPD zjišťuje, zda je peer naživu; zvýšení jeho časového limitu nesladí volby ESP ani PFS.
Zaznamenejte vyjednaný výsledek a další událost po změně. Pokud nyní spojení selhává dřív, než se dokončí autentizace IKE, díváte se na nastavení IKE, které jste právě upravili, ne na původní selhání obnovy CHILD.