IKEv2 er ikkje éin handtrykk: IKE SA, autentisering og deretter CHILD SA

Du trur kanskje at ein IKEv2-tilkopling er éin utveksling som endar med kryptert trafikk. Det er minst to, og den første autentiserer ingen. Partane startar med kontrollmeldingar, blir samde om kryptografiske parameter, provar identitet og forhandlar først deretter om tilstanden som ber applikasjonspakkar. Den rekkjefølgja forklarar misforholdet folk rapporterer heile tida: gatewayen svarar, klienten seier tilkopla, og den private applikasjonen får framleis tidsavbrot. Her er kva kvart steg faktisk gjer, og kva som må vere sant etterpå.

Myten: viss gatewayen svarar, er du tilkopla

Eit svar på den første meldinga provar at endepunktet er nåbart og vil snakke. Det provar ikkje at ein konto vart godteken, at ei sertifikatkjede vart validert, eller at noka datapolicy vart installert.

Desse feila skjer seinare, og dei gir ulike symptom. Ei sertifikatavvising eller ein EAP-feil kjem etter at den første utvekslinga alt har lukkast, difor seier ein ping til UDP 500 og eit grønt klientikon så lite.

IKE_SA_INIT: bli samde om parameter, ikkje identitet

Den første utvekslinga ber forslaga til IKE-tryggingsassosiasjonen: krypterings- og integritetsalgoritmar, ein pseudotilfeldig funksjon og ein Diffie-Hellman-gruppe. Partane utvekslar også nonce-verdiar, og kvar side leier ut nøkkelmateriale for IKE SA frå den delte løyndomen som desse verdiane skaper. Ingenting i denne utvekslinga fastslår kven den andre parten er. Ho fastslår at begge sider kan rekne ut dei same nøklane og at dei er samde om eit forslag. Ein svarar som ikkje likar noko forslag avviser utvekslinga her, difor ser ein versjons- eller algoritmeavvik ut som om tenaren er nede.

IKE SA som blir oppretta på dette punktet, verner alle seinare administrasjonsutvekslingar. Det er jobben hans, og det er ein annan jobb enn å verne pakkane dine.

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

Den andre utvekslinga ber identitet. Med sertifikat signerer kvar part med sin private nøkkel og legg fram ei kjede som den andre må validere; med EAP utfordrar svararen initiativtakaren gjennom den valde metoden. Her kjem endeleg eit feil tenarnamn, eit utlope sertifikat eller eit avvist passord til overflata.

Normalt forhandlar IKE_AUTH også den første CHILD SA, slik at datavemet blir avtalt i same runden. Initiativtakaren føreslår trafikkveljarar, svararen snevrar inn eller avviser dei, og nøklane for databanen blir leidde ut frå IKE SA. Det tyder at éi utveksling kan feile på to svært ulike stader: identitet eller policy. Les varselnyttelasta eller feilen i staden for den generiske handtrykkfeilen, fordi rettinga for det eine er eit sertifikat og for det andre eit subnettavvik.

To SA, to jobbar

Å halde dei frå kvarandre forklarar to oppførsler som ser ut som feil. Ein tunnel kan visast som etablert medan nøkkelfornying feilar i bakgrunnen, og ein CHILD SA kan bytast ut utan at klienten mistar tilkoplinga.

På strongSwan viser IKEv2-konfigurasjonsreferansen og swanctl --list-sas begge nivåa, og ip xfrm state samt ip xfrm policy viser kva kjernen faktisk installerte. Å samanlikne desse to visingane er den snøggaste måten å sjå om forhandlinga vart fullført eller berre såg fullført ut. Viss daemonen listar ein CHILD SA som kjernen ikkje har tilstand for, mislukkast installasjonen i det stille. Viss kjernen har tilstand som daemonen ikkje kjenner, ser du ein rest frå eit tidlegare forsøk.

Kva som framleis må vere sant etter at tunnelen er oppe

Trafikkveljarane definerer kva adresser som er dekte. Viss klienten føreslår eitt subnett og tenaren ventar eit anna, blir CHILD SA installert, men han ber ingenting nyttig, og feilen viser seg som eit ruteproblem og ikkje eit forhandlingsproblem. Deretter må den lokale stakken samarbeide: videresending aktivert der verten ruter, ruter mot tunnelen, brannmurreglar som tillèt dei dekapsulerte pakkane, og ein intern oppløysar viss private namn er involverte. Kvar av desse feilar separat, og ingen av dei blir retta ved å starte IKE-daemonen på nytt.

Hald loggen synleg medan du diagnostiserer: den første utvekslinga, deretter identitetsvalidering, så brukarautentisering der det gjeld, så CHILD-installasjon og til slutt applikasjonstrafikk. Steget som stoggar er steget som skal rettast, og ein seinare rutefeil er aldri grunn til å lempe på identitetskontrollane som alt har passert.