Korleis IKEv1 hybridautentisering blir overført til IKEv2 brukarautentisering
Hybridmodusen skilde beviset til gatewayen frå beviset til brukaren. Overgangen til IKEv2 held på denne delinga, men endrar utvekslinga, EAP-metoden og sertifikatkontrollane.
Kvar gamal VPN-profil som først ber om eit servertsertifikat og deretter eit brukarnamn, ber to autentiseringshendingar i éi utveksling, og den forma overlever protokollen som innførte ho. IKEv1 hybridmodus vart bygd nettopp for dette: gatewayen beviser seg med ein offentleg nøkkel medan brukaren beviser seg seinare via XAuth. IKEv2 uttrykkjer den same totrinnstanken med annan mekanikk, og det er i desse skilnadene migreringar feilar. Ikkje noko versjonsnummer konverterer den eine til den andre, og å kopiere dei gamle alternativnamna inn i ein ny profil gjev ein klient som forhandlar og deretter ikkje autentiserer noko.
Kva hybridmodusen gjorde inne i IKEv1
I ein hybridprofil signerer svararen fase-ein-utvekslinga med sertifikatet sitt medan initiatoren medvite ikkje viser noko. Identitetsbeviset er dimed asymmetrisk, og det var dette som lét ein gateway behalde sin eksisterande PKI medan brukarane behaldt katalogpassorda sine. Når fase ein er ferdig, køyrer XAuth som ein førespurnad og eit svar som ber brukarnamn- og passordattributt inne i den no krypterte ISAKMP-kanalen.
Legg merke til kvar tilliten landar. Sertifikatet svarar på kva gateway klienten nådde; XAuth svarar på kva brukar som vil ha tilgang. Ingen av dei erstattar den andre, og ein klient sett opp til å godta eit kva som helst servertsertifikat har stille kasta det første svaret. Etiketten hybrid vert også brukt om aggressive mode med førehandsdel nøkkel pluss XAuth, ei anna ordning med same brukaroppleving, så les profilen og ikkje namnet. Begge variantane stammar frå utkast som aldri vart standardar, og difor kan to leverandørar implementere hybridmodus og ikkje samverke med nokon.
Korleis IKEv2 når dei same to bevisa
IKEv2 deler arbeidet mellom IKE_SA_INIT og IKE_AUTH. Den første utvekslinga avtalar forslag og nøklar heilt utan identitetar; den andre ber IDi, IDr og AUTH-nyttelastane. Under EAP går den første AUTH-nyttelasta til initiatoren tom ut, svararen autentiserer seg først med sertifikat og signatur, og deretter går EAP-samtalen inne i IKE_AUTH-meldingane.
Mekanismen som gjer dette trygt, er nøkkelmateriale. Ein vellukka EAP-metode eksporterer ein sesjonsnøkkel, og den endelege AUTH-nyttelasta til initiatoren vert rekna ut frå han, slik at beviset til brukaren og nøklane til tunnelen er bundne saman. XAuth har ingen motpart: attributta kjem etter fase ein og bidreg ikkje med noko til nøklane. Nettopp det gapet vart IKEv2-rammeverket utforma for å lukke, og difor validerer ei fungerande IKEv2-innlogging servertsertifikatet før ho spør om noko.
Denne rekkjefølgja er også ein nyttig diagnose. Når ein klient klagar over påloggingsinformasjon før han har vist deg eit sertifikat, gjer han slett ingen IKEv2 EAP-utveksling.
Hald tre identitetar åtskilde
Ei migrering går gale når tre identitetar fell saman i eitt felt. Der er gateway-identiteten klienten validerer, vanlegvis eit DNS-namn i subject eller SAN til sertifikatet. Der er brukaridentiteten som vert presentert i EAP, kanskje ei domenepålogging, ei adresse eller ein eksplisitt EAP-identitetsstreng. Og der er autorisasjonskjelda som mappar den brukaren til nettverk og ruter.
swanctl-syntaksen til strongSwan gjer delinga synleg: sambandet set remote { auth = pubkey } for gatewayen og local { auth = eap-mschapv2 } for brukaren, med EAP-identiteten boren separat.
Når brukaridentiteten i den nye profilen avvik frå dei gamle XAuth-attributta, til dømes ein UPN i staden for eit kort namn, ser autentiseringsserveren ein ukjend brukar, og feilen ser ut som eit feil passord. Kontroller identitetsstrengen før du kontrollerer påloggingsinformasjonen.
Kartlegg alternativa og vent deretter på fellene
Kartlegginga er kort, og kvar rad har ei felle som først dukkar opp ved autentisering.
| 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 av desse radene er ei enkel namneendring. Konfigurasjonsnyttelasta leverer adresser og resolvar via ei typa attributtliste, medan attributtrommet til XAuth var hans eiga oppfinning; å handsame dei som utbyttbare er korleis ein profil endar med å be om ei innstilling gatewayen aldri vil sende.
Trafikkveljarar fortener si eiga åtvaring. IKEv1 uttrykte interessant trafikk via proxy-ID-ar bundne til ei quick mode-utveksling, medan IKEv2 forhandlar veljarane under IKE_AUTH og svararen kan snevre dei inn. Eit mishøve gjev ein etablert IKE SA utan child SA, som somme klientar gladeleg viser som tilkopla.
Behandle det gamle sambandet som ei grense
RFC 9395 avskriv IKEv1, så eit gamalt hybridsamband er ei kompatibilitetsgrense med ein dato på, ikkje eit fundament. Køyr begge profilane side om side under bytet, for testen som betyr noko er ikkje om den nye profilen kjem opp, men om den same brukaren på same eining når dei same ressursane.
Hald sertifikatvalideringa streng heile vegen. Når klienten sluttar å vise sitt eige sertifikat, er freistinga å lempe på serverkontrollen til handtrykket går gjennom, og det byter det einaste attverande beviset mot eit grønt ikon.
Skriv ned fire ting før du pensjonerer den gamle profilen: EAP-metoden, identitetsstrengen, autorisasjonskjelda og datoen då støtta tek slutt.