IKEv2 nie je jedno podanie ruky: IKE SA, autentifikácia, potom CHILD SA

Možno si myslíte, že spojenie IKEv2 je jedna výmena, ktorá sa končí šifrovaním prevádzky. Sú najmenej dve a prvá nikoho neautentifikuje. Strany začínajú riadiacimi správami, dohodnú kryptografické parametre, preukážu identitu a až potom vyjednajú stav, ktorý prenáša pakety aplikácie. Toto poradie vysvetľuje nezrovnalosť, ktorú ľudia neustále hlásia: brána odpovedá, klient hlási pripojenie, a súkromná aplikácia predsa vyprší. Tu je, čo každá fáza naozaj robí a čo musí platiť po nej.

Mýtus: ak brána odpovie, ste pripojený

Odpoveď na prvú správu dokazuje, že koncový bod je dosiahnuteľný a ochotný hovoriť. Nedokazuje, že bol účet prijatý, že reťazec certifikátov bol overený alebo že bola nainštalovaná nejaká dátová politika.

Tieto zlyhania prichádzajú neskôr a majú iné príznaky. Odmietnutie certifikátu alebo zlyhanie EAP prichádza až po úspešnej prvej výmene, preto ping na UDP 500 a zelená ikona klienta povedia tak málo.

IKE_SA_INIT: dohodnite parametre, nie identitu

Prvá výmena nesie návrhy pre bezpečnostnú asociáciu IKE: algoritmy šifrovania a integrity, pseudonáhodnú funkciu a skupinu Diffie-Hellman. Strany si tiež vymieňajú nonce a každá strana odvodí kľúčový materiál pre IKE SA zo spoločného tajomstva, ktoré tieto hodnoty vytvárajú. Nič v tejto výmene neurčuje, kto je druhá strana. Určuje len, že obe strany vedia vypočítať rovnaké kľúče a zhodujú sa na jednom návrhu. Odpovedajúci, ktorému sa nepáči žiadny návrh, tu výmenu odmietne, preto nezgoda verzie alebo algoritmu vyzerá ako spadnutý server.

IKE SA vytvorená v tomto bode chráni všetky neskoršie riadiace výmeny. To je jej úloha a je to iná úloha než chrániť vaše pakety.

IKE_AUTH: preukážte identitu a potom postavte prvý CHILD SA

Druhá výmena nesie identitu. S certifikátmi každá strana podpíše svojím súkromným kľúčom a predloží reťazec, ktorý druhá musí overiť; s EAP odpovedajúci vyzve iniciátora zvolenou metódou. Tu sa konečne objaví nesprávne meno servera, expirovaný certifikát alebo odmietnuté heslo.

Zvyčajne IKE_AUTH vyjedná aj prvý CHILD SA, takže ochrana dát sa dohodne v tom istom kole. Iniciátor navrhne selektory prevádzky, odpovedajúci ich zúži alebo odmietne, a kľúče dátovej cesty sa odvodia z IKE SA. To znamená, že jedna výmena môže zlyhať na dvoch veľmi odlišných miestach: v identite alebo v politike. Čítajte oznámenie alebo chybu, nie všeobecné zlyhanie podania ruky, lebo jedno sa lieči certifikátom a druhé nezhodou podsiete.

Dve SA, dve úlohy

Ich oddelenie vysvetľuje dve správania, ktoré vyzerajú ako chyby. Tunel môže vyzerať vytvorený, kým na pozadí zlyháva obnova kľúčov, a CHILD SA možno vymeniť bez toho, aby klient stratil spojenie.

V strongSwane referencia konfigurácie IKEv2 a swanctl --list-sas ukazujú obe úrovne a ip xfrm state spolu s ip xfrm policy ukazujú, čo jadro naozaj nainštalovalo. Porovnanie týchto dvoch pohľadov je najrýchlejší spôsob, ako zistiť, či sa vyjednávanie skončilo alebo len vyzeralo skončené. Ak démon uvedie CHILD SA, pre ktorú jadro nemá stav, inštalácia ticho zlyhala. Ak jadro drží stav, o ktorom démon nevie, pozeráte sa na zvyšok predchádzajúceho pokusu.

Čo ešte musí platiť po zdvihnutí tunela

Selektory prevádzky určujú, ktoré adresy sú pokryté. Ak klient navrhne jednu podsietu a server očakáva inú, CHILD SA sa nainštaluje, ale nepreváža nič užitočné, a chyba sa javí ako problém smerovania, nie vyjednávania. Potom musí lokálny stack spolupracovať: preposielanie zapnuté tam, kde hostiteľ smeruje, trasy k tunelu, pravidlá firewallu povoľujúce dekapsulované pakety a interný rezolver, ak ide o súkromné mená. Každé z toho zlyháva samostatne a žiadne sa neopraví reštartom démona IKE.

Nechajte log viditeľný pri diagnostike: úvodná výmena, potom overenie identity, potom autentifikácia používateľa, kde sa uplatňuje, potom inštalácia CHILD a nakoniec prevádzka aplikácie. Fáza, ktorá sa zastaví, je tá na opravu, a neskoršie zlyhanie smerovania nikdy nie je dôvodom poľaviť z už prejdených kontrol identity.