IKEv2 is nie net een handskud nie: eers IKE SA, dan verifikasie, dan CHILD SA

Jy mag dink dat ’n IKEv2-verbinding een uitruiling is wat eindig wanneer jou verkeer versleutel is. Dit is ten minste twee, en die eerste een verifieer niemand nie. Die eweknieë begin met beheerboodskappe, stem oor kriptografiese parameters saam, bewys identiteit en onderhandel eers daarna die toestand wat toepassingspakkette dra. Daardie volgorde verduidelik die wanverhouding wat mense gereeld rapporteer: die poort antwoord, die kliënt sê dit is gekonnekteer, en die private toepassing keer steeds met ’n tydsverloop terug. Hier is wat elke stadium werklik doen, en wat daarna waar moet wees.

Die mite: as die poort antwoord, is jy gekonnekteer

’n Antwoord op die eerste boodskap bewys dat die eindpunt bereikbaar is en bereid is om te praat. Dit bewys nie dat ’n rekening aanvaar is, dat ’n sertifikaatketting gevalideer het, of dat enige databeleid geïnstalleer is nie.

Daardie mislukkings gebeur later, en hulle lewer verskillende simptome. ’n Sertifikaatverwerping of ’n EAP-mislukking kom nadat die eerste uitruiling reeds geslaag het, en daarom sê ’n ping na UDP 500 en ’n groen kliëntikoon so min.

IKE_SA_INIT: stem oor parameters saam, nie identiteit nie

Die eerste uitruiling dra voorstelle vir die IKE-veiligheidsvereniging: enkripsie- en integriteitsalgoritmes, ’n pseudotoevallige funksie en ’n Diffie-Hellman-groep. Die eweknieë ruil ook nonces uit, en elke kant lei sleutelmateriaal vir die IKE SA af uit die gedeelde geheim wat daardie waardes voortbring. Niks in hierdie uitruiling stel vas wie die ander party is nie. Dit stel vas dat beide kante dieselfde sleutels kan bereken en dat hulle oor ’n voorstel saamstem. ’n Responsgewer wat van geen voorstel hou nie, verwerp die uitruiling hier, en daarom lyk ’n weergawe- of algoritmeverskil soos ’n bediener wat af is.

Die IKE SA wat op hierdie punt geskep word, beskerm alle latere beheeruitruilings. Dit is sy werk, en dit is ’n ander werk as om jou pakkette te beskerm.

IKE_AUTH: bewys identiteit, bou dan die eerste CHILD SA

Die tweede uitruiling dra identiteit. Met sertifikate onderteken elke eweknie met sy privaatsleutel en bied ’n ketting aan wat die ander moet valideer; met EAP daag die responsgewer die inisieerder uit deur die gekose metode. Hier kom ’n verkeerde bedienernaam, ’n vervalle sertifikaat of ’n verwerpte wagwoord uiteindelik na vore.

In die normale geval onderhandel IKE_AUTH ook die eerste CHILD SA, so die databeskerming word in dieselfde rondte ooreengekom. Die inisieerder stel verkeerskeuses voor, die responsgewer vernou of verwerp hulle, en sleutels vir die datapad word van die IKE SA afgelei. Dit beteken dat ’n enkele uitruiling op twee baie verskillende plekke kan misluk: identiteit of beleid. Lees die kennisgewinglading of fout eerder as die algemene handskudfout, want die oplossing vir die een is ’n sertifikaat en die oplossing vir die ander is ’n subnetverskil.

Twee SAs, twee take

Om hulle apart te hou verduidelik twee gedragings wat soos foute lyk. ’n Tonnel kan as gevestig wys terwyl ’n hersleuteling in die agtergrond misluk, en ’n CHILD SA kan vervang word sonder dat die kliënt die verbinding laat val.

Op strongSwan wys die IKEv2-konfigurasieverwysing en swanctl --list-sas albei vlakke, en ip xfrm state plus ip xfrm policy wys wat die kern werklik geïnstalleer het. Om daardie twee sienings te vergelyk is die vinnigste manier om te sien of die onderhandeling klaar was of net klaar gelyk het. As die daemon ’n CHILD SA lys waarvoor die kern geen toestand het nie, het die installasie stil misluk. As die kern toestand hou waarvan die daemon nie weet nie, kyk jy na ’n oorblyfsel van ’n vroeër poging.

Wat nog waar moet wees nadat die tonnel op is

Verkeerskeuses bepaal watter adresse gedek word. As die kliënt een subnet voorstel en die bediener ’n ander verwag, word die CHILD SA geïnstalleer maar dra niks nuttigs nie, en die fout verskyn as ’n roeteringsprobleem eerder as ’n onderhandelingsprobleem. Dan moet die plaaslike stapel saamwerk: aanstuur geaktiveer waar die gasheer roeteer, roetes wat na die tonnel wys, brandmuurreëls wat die ontdopte pakkette toelaat, en ’n interne oplosser as private name ter sprake is. Elkeen van hierdie misluk afsonderlik, en nie een word reggestel deur die IKE-daemon te herbegin nie.

Hou die log sigbaar terwyl jy diagnoseer: die aanvanklike uitruiling, dan identiteitsvalidering, dan gebruikerverifikasie waar dit van toepassing is, dan CHILD-installasie, dan toepassingsverkeer. Die stadium wat stop is die stadium om reg te maak, en ’n latere roeteringsfout is nooit ’n rede om die identiteitskontroles wat reeds geslaag het, te verslap nie.