IKEv2: obnovení klíčů versus opakovaná autentizace — proč spojení později padá

Tunel se ráno zvedne a funguje hodiny. Pak spadne, po pokusu se znovu připojí a další den udělá totéž. V síti se nic nezměnilo a nikdo nesáhl na heslo. Relace, které selhávají na hranici obnovení, obvykle překračují jednu ze dvou různých operací a jen jedna z nich znovu ověřuje vaše přihlašovací údaje. Přečíst, která z nich zabrala, je celá diagnóza.

Dvě operace, které zvenčí vypadají stejně

Obnovení klíčů nahrazuje bezpečnostní asociace nebo klíčový materiál v rámci výměny definované protokolem. Autentizace se neopakuje, takže identita přijatá na začátku relace se prostě přenáší dál.

Opakovaná autentizace jde dál: vytváří nový autentizovaný vztah, což znamená, že se přihlašovací údaje znovu vyhodnocují. Vše, co vypršelo, bylo odvoláno nebo se v adresáři změnilo, se v tu chvíli projeví.

Co obnovení klíčů skutečně nahrazuje

IKEv2 drží dva druhy asociací s oddělenými životními cykly. IKE SA chrání řídicí kanál a CHILD SA chrání skutečný provoz. Obnovit jednu není totéž jako znovu připojit klienta.

To oddělení vysvětluje známý vzorec: provoz jde dobře, pak se CHILD SA obnoví a návrh už nesedí, protože někdo před týdny upravil fázi 2 na jedné straně. Změna tam ležela neškodně, dokud ji obnovení neuvedlo v činnost.

Nesoulad životností se chová stejně. Strana, která první dosáhne svého limitu, zahájí výměnu a druhá ji musí přijmout.

Co opakovaná autentizace znovu vyhodnocuje

Při opakované autentizaci může být klientský certifikát, který byl platný při přihlášení, už propadlý. Odvolané přihlašovací údaje, rotované heslo nebo nedostupný druhý faktor se objeví právě tady, ne v době obnovení.

Proto prodloužení každé životnosti vypadá jako oprava a není. Ověření jste odložili, místo abyste ho prošli. Další obnovení přijde se stejnou vadou a s kratším oknem, kdy si jí všimnout.

Některé implementace při opakované autentizaci překrývají starý a nový stav. Jiné vytvoří krátkou mezeru. Stejná nastavení u dvou dodavatelů proto mohou dát odlišnou uživatelskou zkušenost. Testujte chování, místo abyste předpokládali, že ho standard ukládá.

Přečtěte si časové značky, než cokoli změníte

Zachyťte okamžik selhání spolu se stavem asociace před a po. Pokud byla stará asociace nahrazena bez autentizační výměny, byli jste na hranici obnovení. Pokud se těsně před selháním objeví výměna AUTH, byli jste u opakované autentizace.

strongSwan to vystavuje jako samostatná nastavení: rekey řídí obnovení klíčů, reauth řídí, zda proběhne nová autentizace, a hodnoty margin rozhodují, jak dlouho před vypršením každá začne. dokumentace k obnovení klíčů popisuje tuto interakci a stojí za přečtení, než zkopírujete životnost z příspěvku na fóru.

Rozlišujte to vše od prosté ztráty sítě. Přerušený spoj vytvoří událost detekce mrtvého protějšku nebo bouři opakovaných přenosů, ne čistou výměnu se shodnými návrhy.

Změňte to, co selhalo

Odmítnutí přihlašovacích údajů vyžaduje opravit problém identity: obnovte certifikát, obnovte účet, znovu zaregistrujte faktor. Nesoulad návrhu nebo životnosti vyžaduje srovnat parametry na obou stranách.

Prodlužování životností, aby se symptomu vyhnulo, je jediná možnost, která vždy vypadá, že zabrala, a nikdy nezabere.

Vyzkoušejte řízené obnovení

Vynuťte obnovení, místo abyste na něj čekali den. Pak to zopakujte s opakovanou autentizací, pokud ji nasazení podporuje, a sledujte oba konce.

Úspěšné první přihlášení nic z toho neprocvičí. Životní cyklus po něm je místo, kde se tato nasazení skutečně lámou.