Sådan overføres IKEv1-hybridgodkendelse til IKEv2-brugergodkendelse
Hybridtilstanden adskilte gatewayens bevis fra brugerens bevis. Skiftet til IKEv2 bevarer den adskillelse, men ændrer udvekslingen, EAP-metoden og certifikatkontrollen.
Enhver gammel VPN-profil, der først beder om et servercertifikat og derefter om et brugernavn, bærer to godkendelseshændelser i én udveksling, og den form overlever det protokol, der indførte den. IKEv1-hybridtilstand blev bygget præcis til dette: gatewayen beviser sig med en offentlig nøgle, mens brugeren beviser sig senere via XAuth. IKEv2 udtrykker den samme totrinsidé med andre mekanismer, og det er i de forskelle, migrationer fejler. Intet versionsnummer konverterer den ene til den anden, og kopierer man de gamle mulighedsnavne ind i en ny profil, får man en klient, der forhandler og derefter ikke godkender noget.
Hvad hybridtilstanden gjorde inde i IKEv1
I en hybridprofil signerer respondereren fase-et-udvekslingen med sit certifikat, mens initiatoren bevidst ikke fremviser noget. Identitetsbeviset er derfor asymmetrisk, og det var det, der lod en gateway beholde sin eksisterende PKI, mens brugerne beholdt deres mappeadgangskoder. Når fase et er færdig, kører XAuth som en anmodning og et svar, der bærer brugernavns- og adgangskodeattributter inde i den nu krypterede ISAKMP-kanal.
Læg mærke til, hvor tilliden lander. Certifikatet svarer på, hvilken gateway klienten nåede; XAuth svarer på, hvilken bruger der vil have adgang. Ingen af dem erstatter den anden, og en klient, der er sat til at acceptere et vilkårligt servercertifikat, har stille kasseret det første svar. Etiketten hybrid bruges også om aggressive mode med forudelt nøgle plus XAuth, en anden indretning med samme brugeroplevelse, så læs profilen og ikke navnet. Begge varianter stammer fra udkast, der aldrig blev standarder, og derfor kan to leverandører implementere hybridtilstand og ikke interopere med nogen.
Hvordan IKEv2 når de samme to beviser
IKEv2 deler arbejdet mellem IKE_SA_INIT og IKE_AUTH. Den første udveksling aftaler forslag og nøgler helt uden identiteter; den anden bærer IDi, IDr og AUTH-nyttelasterne. Under EAP går initiatorens første AUTH-nyttelast tom ud, respondereren godkender sig først med certifikat og signatur, og derefter kører EAP-samtalen inde i IKE_AUTH-beskederne.
Mekanismen, der gør dette sikkert, er nøglemateriale. En vellykket EAP-metode eksporterer en sessionsnøgle, og initiatorens endelige AUTH-nyttelast beregnes ud fra den, så brugerens bevis og tunnelens nøgler bindes sammen. XAuth har ingen pendant: dens attributter ankommer efter fase et og bidrager intet til nøglerne. Det hul er præcis, hvad IKEv2-rammen blev designet til at lukke, og derfor validerer et fungerende IKEv2-login servercertifikatet, før det spørger om noget.
Den rækkefølge er også en nyttig diagnose. Når en klient klager over legitimationsoplysninger, før den har vist dig et certifikat, laver den slet ikke en IKEv2 EAP-udveksling.
Hold tre identiteter adskilt
En migration går galt, når tre identiteter falder sammen i ét felt. Der er gatewayidentiteten, som klienten validerer, normalt et DNS-navn i certifikatets subject eller SAN. Der er brugeridentiteten, som præsenteres i EAP, måske et domænelogin, en adresse eller en eksplicit EAP-identitetsstreng. Og der er autorisationskilden, der mapper den bruger til netværk og ruter.
strongSwan-syntaksen swanctl gør opdelingen synlig: forbindelsen sætter remote { auth = pubkey } for gatewayen og local { auth = eap-mschapv2 } for brugeren, med EAP-identiteten båret separat.
Når brugeridentiteten i den nye profil afviger fra de gamle XAuth-attributter, for eksempel et UPN i stedet for et kort navn, ser godkendelsesserveren en ukendt bruger, og fejlen ligner en forkert adgangskode. Kontroller identitetsstrengen, før du kontrollerer legitimationsoplysningerne.
Kortlæg mulighederne, og forvent fælderne
Kortlægningen er kort, og hver række har en fælde, der først dukker op ved godkendelsen.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Ingen af de rækker er en simpel omdøbning. Konfigurationsnyttelasten leverer adresser og resolvere via en typet attributliste, mens XAuths attributrum var dens egen opfindelse; at behandle dem som udskiftelige er, hvordan en profil ender med at bede om en indstilling, gatewayen aldrig sender.
Trafikvælgere fortjener deres egen advarsel. IKEv1 udtrykte interessant trafik via proxy-ID'er bundet til en quick-mode-udveksling, mens IKEv2 forhandler vælgere under IKE_AUTH, og respondereren kan indsnævre dem. Uoverensstemmelse giver en etableret IKE SA uden child SA, som nogle klienter gladeligt viser som forbundet.
Behandl den gamle forbindelse som en grænse
RFC 9395 nedskriver IKEv1, så en gammel hybridforbindelse er en kompatibilitetsgrænse med en dato på, ikke et fundament. Kør begge profiler side om side under skiftet, for den test, der betyder noget, er ikke, om den nye profil kommer op, men om den samme bruger på samme enhed når de samme ressourcer.
Hold certifikatvalideringen streng hele vejen. Når klienten stopper med at fremvise sit eget certifikat, er fristelsen at slække på serverkontrollen, indtil håndtrykket går igennem, og det bytter det eneste tilbageværende bevis for et grønt ikon.
Skriv fire ting ned, før du pensionerer den gamle profil: EAP-metoden, identitetsstrengen, autorisationskilden og datoen, hvor supporten ophører.