FortiGate Azure kulcsújrakérés: a peer SA javaslat nem egyezik a helyi házirenddel
Egy működő IKEv2-alagút is elutasíthatja a helyettesítő CHILD SA-t. Hasonlítsa össze azt a javaslatot, amelyről a megújítás valóban tárgyal, ne azt, amelyet az első ping használt.
Az alagút feljött, a forgalom folyt, majd később a napló ezt írja: peer SA proposal not match local policy. A legtöbben ezt a sort annak bizonyítékaként olvassák, hogy a két konfiguráció soha nem egyezett. Általában szűkebb dolgot jelent: az első CHILD SA-nál egyeztek, és az első megújításnál már nem, mert az első társításnak soha nem kellett az a csere, amelyet a későbbiek végeznek. Ez a különbség dönti el, hol keressen.
Az első CHILD SA örököl, a későbbiek tárgyalnak
Az IKEv2-ben a kezdeti CHILD SA az IKE_AUTH során jön létre, kulcsai az IKE SA kulcsanyagából származnak. Ekkor nincs külön Diffie-Hellman-csere, így egy olyan PFS-csoportot, amelyet az egyik peer nem tud elfogadni, egyszerűen még nem próbálnak ki. Az alagút egészségesnek látszik, mert azt a követelményt, amelynél később elbukik, soha nem tesztelték.
A CHILD_SA kulcsújrakérés más üzenetsorrend. Ha a PFS be van állítva, a peerek friss kulcscserét folytatnak, és meg kell egyezniük egy mindkét fél által elfogadott csoportban, valamint az új társítás ESP-javaslatában. Ebben a pillanatban válik láthatóvá az eltérés, és ezért nevez meg a hiba javaslatot, nem pedig útvonalat.
Tehát a „tegnap működött” semmit sem mond a javaslatról. Azt mondja, hogy a kezdeti csere sikeres volt, amit már tudott.
A sikertelen cserét olvassa, ne az első pinget
Mielőtt bármit módosítana, gyűjtse össze mindkét oldalról a sikeres IKE-hitelesítést, a kezdeti CHILD SA-t és a sikertelen helyettesítést. Utána nevezze meg pontosan a műveletet: az IKE SA kulcsújrakérés, az IKE újrahitelesítés és a CHILD SA kulcsújrakérés három különböző esemény, és a „2. fázis” a köznyelvben mindegyiket lefedi.
Hasonlítsa össze az alábbi mezőket a sikertelen kapcsolatnál, ne az alagútnál általában.
| Réteg | Összehasonlítandó értékek |
|---|---|
| IKE | Verzió, titkosítás és integritás vagy PRF-elrendezés, DH-csoport |
| IPsec / CHILD | ESP-titkosítás és -integritás, tervezett PFS- vagy kulcscsere-csoport |
| Védett forgalom | Helyi és távoli szelektorok, valamint bármilyen házirend-alapú szelektorbeállítás |
A FortiGate-en nyissa meg az adott alagút 2. fázisú javaslatát, a PFS-beállítást és az elfogadott DH-csoportokat. A betöltött értékeket olvassa ki, ne egy korábban létrejött kapcsolatból következtessen rájuk. A GUI-oldal képernyőképe gyengébb bizonyíték a futó konfigurációnál, mert a kettő frissítés után eltérhet. Exportálja a módosított részt, és őrizze meg a jeggyel együtt.
Az Azure alapértelmezett házirendje is házirend
Az, hogy nincs egyéni házirend a kapcsolathoz csatolva, nem jelenti azt, hogy az Azure egyet sem alkalmaz. A kapcsolat visszaáll az átjáró alapértelmezett javaslatkészletére, amely szélesebb vagy szűkebb lehet annál, amit a FortiGate kínál. Ha a két készlet átfed az IKE esetében, de az ESP esetében PFS-sel nem, pontosan ezt a hibaformát kapja.
Ez a csak olvasható nézet a ténylegesen csatolt házirendet mutatja, titkok felfedése nélkül:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesHasználja a valódi erőforrásneveit. Ha kifejezett házirendre van szükség, állítsa be a kapcsolat erőforrásán. Ez nem átjárószintű kapcsoló, és nem vonatkozik csendben az ugyanazon az átjárón lévő többi alagútra.
A portálon a Configuration oldal az, ahová az egyéni IPsec/IKE házirend kerül. A Microsoft egyéni házirendekről szóló útmutatója felsorolja a támogatott paramétereket és az SKU-követelményeket. Az Azure kapcsolatonként egyetlen teljes kombinációt vesz át, tehát az IKE-mezőket és az IPsec-mezőket együtt adja meg, nem egyenként.
A PFS követelmény, nem átbillenthető kapcsoló
Ha a biztonsági alapvonala PFS-t ír elő, a megoldás egy olyan csoport, amelyet mindkét peer elfogad mindkét oldalon, és amelyet egyező házirend fejez ki. A PFS kikapcsolása, hogy a hiba eltűnjön, megváltoztatja azt a biztonsági tulajdonságot, amelyet meg akart tartani, és általában később más eltérésként tér vissza.
Egy Azure-specifikus csapda: amikor GCM-et választ az ESP-hez, a titkosítási és integritási választásoknak ugyanazt a GCM-algoritmust és ugyanazt a kulcshosszt kell megnevezniük. Egy GCM-rejtjel keverése külön integritásalgoritmussal olyan kombinációt ad, amelyet a szolgáltatás elutasít, és ez peer-eltérésnek látszik, amíg figyelmesen el nem olvassa a házirendet.
Válassza a legerősebb kombinációt, amelyet mindkét vég támogat, és az igénye engedélyez, majd írja le a változásnaplóba. A következő ember ahhoz a feljegyzéshez fog hasonlítani, nem egy működő alagút emlékéhez. Tegye bele a PFS-csoportot és az ESP-javaslatot, ne csak a házirend nevét. Ha később valaki azt kérdezi, miért bukott meg egy audit, vagy miért lassú egy kulcsújrakérés, az a sor mindkét kérdésre válaszol.
Ellenőrizze a sikertelen cserét
Tervezze meg a változtatást visszaállítási útvonallal, mert a házirend szerkesztése megszakíthatja az alagutat, amelyet javítani próbál. Amikor a forgalom visszatér, várjon a CHILD_SA-megújításra, vagy indítsa el, és erősítse meg, hogy az új társítás a tervezett PFS-csoporttal jön létre. Utána erősítse meg, hogy az alkalmazásforgalom tovább folyik rajta.
Két zsákutcát érdemes megnevezni. Az SA-élettartamok helyi specifikációk, ezért az egyenlőtlen értékek normálisak, és módosításuk csak eltolja, mikor jelenik meg a probléma. A DPD azt észleli, hogy egy peer él-e; az időkorlát emelése nem hangolja össze az ESP- vagy PFS-választásokat.
Jegyezze fel a kialkudott eredményt és a változtatás utáni következő eseményt. Ha a kapcsolat most az IKE-hitelesítés befejezése előtt meghiúsul, akkor az éppen szerkesztett IKE-beállításokat nézi, nem az eredeti CHILD-megújítási hibát.