Proč váš tunel IPsec funguje až do prvního obnovení klíče CHILD SA
Tunel, který přenáší provoz, prokázal nastavení IKE, ne výměnu klíčů použitou při obnovení. Podívejte se, kde se skrývá nesoulad PFS a jak ho vytáhnout na světlo.
Tunel se zvedl, ping odpověděl a všichni podepsali. O čtyři hodiny později relace spadne, strany zalogují chybu v návrhu nebo ve výměně klíčů a první domněnka je, že se v síti něco změnilo. Nic se nezměnilo. Tunel, který přenáší provoz, prokázal, že se obě strany shodují na tom, jak se autentizovat a jak chránit první podřízenou asociaci, a neprokázal nic o výměně klíčů, kterou budou vyžadovat při obnovení. Nesoulad sedí v mezeře mezi těmito dvěma událostmi.
Připojení neznamená, že nastavení PFS souhlasí
U IKEv2 vzniká první podřízená asociace během autentizační výměny a její klíče se odvozují z materiálu, který asociace IKE už vytvořila. Pro tuto podřízenou asociaci neprobíhá samostatná výměna Diffie-Hellman, takže zásada, která ji vyžaduje při obnovení, se při zvednutí neprověřuje.
Obnovení je jiná výměna. Když se obnovuje klíč podřízené asociace, strany mohou provést novou výměnu klíčů se skupinou uvedenou v jejich návrzích, a to je první okamžik, kdy se nastavení skupin porovnávají. Dvě strany, které se neshodují, se tedy mohou autentizovat, nainstalovat podřízenou asociaci a propustit provoz, a potom selhat při obnovení.
Kde se nesoulad skrývá v řetězci návrhu
Ve strongSwan se skupina připojuje k návrhu podřízené asociace, a proto řetězec jako aes256gcm16-prfsha256-ecp256 vypadá jako volba šifrování, ale nese i požadavek na výměnu klíčů. Strana, která nabízí jen aes256gcm16-prfsha256 nemá takový požadavek, a oba seznamy se protínají v šifrování, ale rozcházejí se ve výměně.
Čtěte návrh podřízené asociace a návrh IKE jako oddělené seznamy. Skupina, která se objeví v seznamu IKE, neříká nic o seznamu podřízené asociace, a upravovat jeden při čtení druhého je obvyklý způsob, jak to přehlédnout.
Čtěte selhání, ne soubor, který jste upravili
Najděte notify, který výměnu ukončil. Obnovení klíče podřízené asociace, které vrátí „žádný přijatelný návrh“, ukazuje na seznamy návrhů; žádost o obnovení, která nikdy nedostane odpověď, ukazuje na cestu nebo na stranu, která přestala poslouchat. Tyto dva případy chtějí různé opravy a formulace řádku v logu je odděluje.
Potvrďte běžící konfiguraci, ne tu na disku. Soubor uložený, ale nenačtený, nebo spojení znovu načtené z jiného include, vytvoří nesoulad, který žádné úpravy viditelného souboru nespraví.
Tři události, kterým všichni říkají obnovení klíče
Obnovení klíče asociace IKE, opětovná autentizace IKE a obnovení klíče podřízené asociace jsou samostatné operace se samostatnými pravidly návrhů. Selhání hlášené u jedné z nich neříká přímo nic o ostatních, a log, který je míchá, se čte jako jediná opakující se závada, i když jsou tři.
Všimněte si, kterou událost strana pojmenuje, a pak zkontrolujte návrhy jen pro tuto událost. Změňte jeden seznam, znovu načtěte a znovu vynuťte stejnou událost. Pokud log pojmenuje opětovnou autentizaci, číst se má návrh IKE. Pokud pojmenuje obnovení klíče podřízené asociace, nese důležitou skupinu návrh podřízené asociace.
Vypnutí obnovování není oprava
Nastavení času obnovení klíče na nulu potlačí výměnu, která selhává, a tunel pak přežije, dokud se nerozpojí nebo dokud se strana nerestartuje. Koupili jste delší životnost klíče a nesoulad, který vás znovu potká při migraci, auditu nebo aktualizaci od dodavatele. Totéž platí pro životnosti natažené daleko za zásadu, kterou druhá strana očekává.
Místo toho návrhy sjednoťte. Vyberte skupinu, kterou obě strany implementují, dejte ji do návrhu podřízené asociace na obou koncích a udržte zásadu obnovování v rozsahu, který organizace skutečně vyžaduje.
Dokažte to výměnou, která selhala
Zkraťte čas obnovení klíče podřízené asociace v servisním okně, aby událost přišla v minutách, ne v hodinách, nebo spusťte ruční obnovení. Pak sledujte úspěšné obnovení a potvrďte, že provoz jím dál prochází, protože nový handshake, který nainstaluje podřízenou asociaci, ale zahodí tok aplikace je jiná závada.
Potom obnovte normální životnost a uchovejte oba záznamy událostí, ten neúspěšný i ten úspěšný. Důkaz, který chcete, je, že spojení přežije vlastní životní cyklus, ne že přežilo ping.