Hvordan IKEv1 hybridautentisering overføres til IKEv2 brukerautentisering
Hybridmodusen skilte beviset fra gatewayen fra beviset fra brukeren. Overgangen til IKEv2 beholder denne delingen, men endrer utvekslingen, EAP-metoden og sertifikatkontrollene.
Hver gammel VPN-profil som først ber om et servertsertifikat og deretter et brukernavn, bærer to autentiseringshendelser i én utveksling, og den formen overlever protokollen som innførte den. IKEv1 hybridmodus ble bygget nettopp for dette: gatewayen beviser seg med en offentlig nøkkel mens brukeren beviser seg senere via XAuth. IKEv2 uttrykker den samme totrinnsideen med annen mekanikk, og det er i disse forskjellene migreringer feiler. Intet versjonsnummer konverterer den ene til den andre, og å kopiere de gamle alternativnavnene inn i en ny profil gir en klient som forhandler og deretter ikke autentiserer noe.
Hva hybridmodusen gjorde inne i IKEv1
I en hybridprofil signerer responderen fase-en-utvekslingen med sertifikatet sitt mens initiatoren bevisst ikke viser noe. Identitetsbeviset er derfor asymmetrisk, og det var dette som lot en gateway beholde sin eksisterende PKI mens brukerne beholdt katalogpassordene sine. Når fase en er ferdig, kjører XAuth som en forespørsel og et svar som bærer brukernavn- og passordattributter inne i den nå krypterte ISAKMP-kanalen.
Legg merke til hvor tilliten lander. Sertifikatet svarer på hvilken gateway klienten nådde; XAuth svarer på hvilken bruker som vil ha tilgang. Ingen av dem erstatter den andre, og en klient satt opp til å godta et hvilket som helst servertsertifikat har stille kastet det første svaret. Etiketten hybrid brukes også om aggressive mode med forhåndsdelt nøkkel pluss XAuth, en annen ordning med samme brukeropplevelse, så les profilen og ikke navnet. Begge variantene stammer fra utkast som aldri ble standarder, og derfor kan to leverandører implementere hybridmodus og ikke samvirke med noen.
Hvordan IKEv2 når de samme to bevisene
IKEv2 deler arbeidet mellom IKE_SA_INIT og IKE_AUTH. Den første utvekslingen avtaler forslag og nøkler helt uten identiteter; den andre bærer IDi, IDr og AUTH-nyttelastene. Under EAP går initiatorens første AUTH-nyttelast tom ut, responderen autentiserer seg først med sertifikat og signatur, og deretter går EAP-samtalen inne i IKE_AUTH-meldingene.
Mekanismen som gjør dette trygt, er nøkkelmateriale. En vellykket EAP-metode eksporterer en sesjonsnøkkel, og initiatorens endelige AUTH-nyttelast beregnes fra den, slik at brukerens bevis og tunnelens nøkler bindes sammen. XAuth har ingen motpart: attributtene kommer etter fase en og bidrar ikke med noe til nøklene. Nettopp det gapet ble IKEv2-rammeverket designet for å lukke, og derfor validerer en fungerende IKEv2-innlogging servertsertifikatet før den spør om noe.
Denne rekkefølgen er også en nyttig diagnose. Når en klient klager over påloggingsinformasjon før den har vist deg et sertifikat, gjør den slett ikke noen IKEv2 EAP-utveksling.
Hold tre identiteter atskilt
En migrering går galt når tre identiteter faller sammen i ett felt. Der er gateway-identiteten klienten validerer, vanligvis et DNS-navn i sertifikatets subject eller SAN. Der er brukeridentiteten som presenteres i EAP, kanskje en domenepålogging, en adresse eller en eksplisitt EAP-identitetsstreng. Og der er autorisasjonskilden som mapper den brukeren til nettverk og ruter.
strongSwans swanctl-syntaks gjør delingen synlig: forbindelsen setter remote { auth = pubkey } for gatewayen og local { auth = eap-mschapv2 } for brukeren, med EAP-identiteten båret separat.
Når brukeridentiteten i den nye profilen avviker fra de gamle XAuth-attributtene, for eksempel en UPN i stedet for et kort navn, ser autentiseringsserveren en ukjent bruker, og feilen ser ut som et feil passord. Kontroller identitetsstrengen før du kontrollerer påloggingsinformasjonen.
Kartlegg alternativene og forvent deretter fellene
Kartleggingen er kort, og hver rad har en felle som først dukker 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 disse radene er en enkel navneendring. Konfigurasjonsnyttelasten leverer adresser og resolvere via en typet attributtliste, mens XAuths attributtrom var dets egen oppfinnelse; å behandle dem som utbyttbare er hvordan en profil ender med å be om en innstilling gatewayen aldri vil sende.
Trafikkvelgere fortjener sin egen advarsel. IKEv1 uttrykte interessant trafikk via proxy-ID-er bundet til en quick mode-utveksling, mens IKEv2 forhandler velgerne under IKE_AUTH og responderen kan snevre dem inn. En mismatch gir en etablert IKE SA uten child SA, som noen klienter gladelig viser som tilkoblet.
Behandle den gamle forbindelsen som en grense
RFC 9395 avskriver IKEv1, så en gammel hybridforbindelse er en kompatibilitetsgrense med en dato på, ikke et fundament. Kjør begge profilene side om side under byttet, for testen som betyr noe er ikke om den nye profilen kommer opp, men om den samme brukeren på samme enhet når de samme ressursene.
Hold sertifikatvalideringen streng hele veien. Når klienten slutter å vise sitt eget sertifikat, er fristelsen å lempe på serverkontrollen til håndtrykket går gjennom, og det bytter det eneste gjenværende beviset mot et grønt ikon.
Skriv ned fire ting før du pensjonerer den gamle profilen: EAP-metoden, identitetsstrengen, autorisasjonskilden og datoen da støtten opphører.