IKEv2 er ikke én håndtrykk: IKE SA, autentisering, deretter CHILD SA

Du tror kanskje at en IKEv2-tilkobling er én utveksling som ender med kryptert trafikk. Det er minst to, og den første autentiserer ingen. Partene starter med kontrollmeldinger, blir enige om kryptografiske parametere, beviser identitet og forhandler først deretter tilstanden som bærer applikasjonspakker. Den rekkefølgen forklarer misforholdet folk rapporterer hele tiden: gatewayen svarer, klienten sier tilkoblet, og den private applikasjonen får fortsatt tidsavbrudd. Her er hva hvert trinn faktisk gjør, og hva som må være sant etterpå.

Myten: hvis gatewayen svarer, er du tilkoblet

Et svar på den første meldingen beviser at endepunktet er nåbart og villig til å snakke. Det beviser ikke at en konto ble godtatt, at en sertifikatkjede ble validert, eller at noen datapolicy ble installert.

Disse feilene skjer senere, og de gir ulike symptomer. En sertifikatavvisning eller en EAP-feil kommer etter at den første utvekslingen allerede har lykkes, derfor sier en ping til UDP 500 og et grønt klientikon så lite.

IKE_SA_INIT: bli enige om parametere, ikke identitet

Den første utvekslingen bærer forslagene til IKE-sikkerhetsassosiasjonen: krypterings- og integritetsalgoritmer, en pseudotilfeldig funksjon og en Diffie-Hellman-gruppe. Partene utveksler også noncer, og hver side utleder nøkkelmateriale for IKE SA fra den delte hemmeligheten som disse verdiene skaper. Ingenting i denne utvekslingen fastslår hvem den andre parten er. Den fastslår at begge sider kan beregne de samme nøklene og at de er enige om et forslag. En svarer som ikke liker noe forslag avviser utvekslingen her, derfor ser en versjons- eller algoritmeavvikelse ut som om serveren er nede.

IKE SA som opprettes på dette punktet beskytter alle senere administrasjonsutvekslinger. Det er jobben dens, og det er en annen jobb enn å beskytte pakkene dine.

IKE_AUTH: bevis identitet, og bygg deretter den første CHILD SA

Den andre utvekslingen bærer identitet. Med sertifikater signerer hver part med sin private nøkkel og legger frem en kjede som den andre må validere; med EAP utfordrer svareren initiativtakeren gjennom den valgte metoden. Her kommer endelig et feil servernavn, et utløpt sertifikat eller et avvist passord til overflaten.

Normalt forhandler IKE_AUTH også den første CHILD SA, slik at databeskyttelsen avtales i samme tur. Initiativtakeren foreslår trafikkvelgere, svareren innsnevrer eller avviser dem, og nøklene for databanen utledes fra IKE SA. Det betyr at én utveksling kan feile på to svært ulike steder: identitet eller policy. Les varselnyttelasten eller feilen i stedet for den generiske håndtrykkfeilen, fordi rettelsen for det ene er et sertifikat og for det andre en subnettavvik.

To SA, to jobber

Å holde dem fra hverandre forklarer to oppførsler som ser ut som feil. En tunnel kan vises som etablert mens nøkkelfornyelse feiler i bakgrunnen, og en CHILD SA kan erstattes uten at klienten mister tilkoblingen.

På strongSwan viser IKEv2-konfigurasjonsreferansen og swanctl --list-sas begge nivåene, og ip xfrm state samt ip xfrm policy viser hva kjernen faktisk installerte. Å sammenligne disse to visningene er den raskeste måten å se om forhandlingen ble fullført eller bare så fullført ut. Hvis daemonen lister en CHILD SA som kjernen ikke har tilstand for, mislyktes installasjonen i stillhet. Hvis kjernen har tilstand som daemonen ikke kjenner, ser du en rest fra et tidligere forsøk.

Hva som fortsatt må være sant etter at tunnelen er oppe

Trafikkvelgerne definerer hvilke adresser som dekkes. Hvis klienten foreslår ett subnett og serveren forventer et annet, installeres CHILD SA, men den bærer ingenting nyttig, og feilen vises som et ruteproblem og ikke et forhandlingsproblem. Deretter må den lokale stakken samarbeide: videresending aktivert der verten ruter, ruter mot tunnelen, brannmurregler som tillater de dekapsulerte pakkene, og en intern oppløser hvis private navn er involvert. Hver av disse feiler separat, og ingen av dem rettes ved å starte IKE-daemonen på nytt.

Hold loggen synlig mens du diagnostiserer: den første utvekslingen, deretter identitetsvalidering, så brukerautentisering der det gjelder, så CHILD-installasjon og til slutt applikasjonstrafikk. Trinnet som stopper, er trinnet som skal rettes, og en senere rutefeil er aldri grunn til å lempe på identitetskontrollene som allerede har passert.