IKEv2 není jediný handshake: nejprve IKE SA, pak autentizace, pak CHILD SA
Odpověď brány dokazuje dostupnost, ne identitu. Sledujte IKE_SA_INIT, IKE_AUTH a první CHILD SA a pak ověřte, co musí platit, než začne proudit provoz.
Možná si myslíte, že připojení IKEv2 je jediná výměna, která končí šifrováním vašeho provozu. Ve skutečnosti jsou alespoň dvě a ta první nikoho neautentizuje. Strany začínají řídicími zprávami, dohodnou kryptografické parametry, prokážou identitu a teprve potom vyjednají stav, který přenáší pakety aplikací. Toto pořadí vysvětluje nesoulad, na který si lidé neustále stěžují: brána odpovídá, klient hlásí připojení, a přesto privátní aplikace končí vypršením času. Zde je, co každá fáze skutečně dělá a co po ní musí platit.
Mýtus: když brána odpoví, jste připojeni
Odpověď na první zprávu dokazuje, že koncový bod je dostupný a ochotný komunikovat. Nedokazuje, že byl přijat účet, že byla ověřena řetězová cesta certifikátů nebo že byla nainstalována nějaká datová politika.
Tato selhání přicházejí později a mají jiné příznaky. Odmítnutí certifikátu nebo selhání EAP dorazí poté, co první výměna už uspěla, a proto ping na UDP 500 a zelená ikona klienta říkají tak málo.
IKE_SA_INIT: dohoda o parametrech, ne o identitě
První výměna nese návrhy pro IKE bezpečnostní asociaci: šifrovací a integritní algoritmy, pseudonáhodnou funkci a skupinu Diffie-Hellman. Strany si také vyměňují nonce a každá strana odvodí klíčový materiál pro IKE SA ze sdíleného tajemství, které tyto hodnoty vytvářejí. Nic v této výměně neurčuje, kdo je druhá strana. Určuje, že obě strany dokážou spočítat stejné klíče a že se shodují na návrhu. Respondent, kterému se nelíbí žádný návrh, výměnu zde odmítne, a proto nesoulad verze nebo algoritmu vypadá jako nedostupný server.
IKE SA vytvořená v tomto okamžiku chrání všechny pozdější řídicí výměny. To je její úkol a je to jiný úkol než chránit vaše pakety.
IKE_AUTH: prokázat identitu, pak vytvořit první CHILD SA
Druhá výměna nese identitu. S certifikáty každá strana podepisuje svým soukromým klíčem a předkládá řetěz, který druhá musí ověřit; s EAP vyzývá respondent iniciátora zvolenou metodou. Právě zde se konečně objeví špatné jméno serveru, propadlý certifikát nebo odmítnuté heslo.
V normálním případě IKE_AUTH vyjednává i první CHILD SA, takže ochrana dat se dohodne ve stejném kole. Iniciátor navrhuje selektory provozu, respondent je zužuje nebo odmítá a klíče pro datovou cestu se odvozují z IKE SA. To znamená, že jediná výměna může selhat na dvou velmi odlišných místech: identita nebo politika. Čtěte notify payload nebo chybu místo obecného selhání handshake, protože jedna příčina se řeší certifikátem a druhá nesouladem podsítě.
Dvě SA, dva úkoly
| Association | Protects | Lifetime behaviour |
|---|---|---|
| IKE SA | Management exchanges: rekeying, delete, configuration payloads | Rekeyed on its own schedule; the data path can survive the change |
| CHILD SA | Application traffic matching the traffic selectors | Rekeyed independently, often more frequently |
Jejich oddělení vysvětluje dvě chování, která vypadají jako chyby. Tunel může vypadat navázaný, zatímco na pozadí selhává obnova klíčů, a CHILD SA lze vyměnit, aniž by klient ztratil spojení.
Na strongSwanu referenční příručka konfigurace IKEv2 a swanctl --list-sas ukazují obě úrovně a ip xfrm state plus ip xfrm policy ukazují, co jádro skutečně nainstalovalo. Porovnání těchto dvou pohledů je nejrychlejší způsob, jak zjistit, zda vyjednávání skončilo, nebo jen vypadalo dokončené. Pokud démon vypíše CHILD SA, pro kterou jádro nemá stav, instalace tiše selhala. Pokud jádro drží stav, o kterém démon neví, díváte se na zbytek dřívějšího pokusu.
Co musí po zvednutí tunelu stále platit
Selektory provozu určují, které adresy jsou pokryty. Pokud klient navrhne jednu podsíť a server očekává jinou, CHILD SA se nainstaluje, ale nenese nic užitečného, a chyba se projeví jako problém směrování, nikoli vyjednávání. Pak musí spolupracovat lokální stack: povolené přeposílání tam, kde hostitel směruje, trasy ukazující do tunelu, pravidla firewallu povolující dekapsulované pakety a interní resolver, pokud jde o privátní názvy. Každé z toho selhává samostatně a žádné se neopraví restartem démona IKE.
Nechte protokol viditelný, dokud diagnostikujete: počáteční výměna, pak ověření identity, pak autentizace uživatele, kde se uplatní, pak instalace CHILD, pak provoz aplikací. Fáze, která se zastaví, je fáze k opravě, a pozdější chyba směrování nikdy není důvodem uvolnit kontroly identity, které už prošly.