Hur IKEv1:s hybridautentisering motsvarar IKEv2:s användarautentisering
Hybridläget skilde gatewayens bevis från användarens bevis. Flytten till IKEv2 behåller den uppdelningen men ändrar utbytet, EAP-metoden och certifikatkontrollerna.
Varje äldre VPN-profil som först begär ett servercertifikat och sedan ett användarnamn bär två autentiseringshändelser i ett enda utbyte, och den formen överlever protokollet som införde den. IKEv1:s hybridläge byggdes just för detta: gatewayen bevisar sig med en publik nyckel medan användaren bevisar sig senare via XAuth. IKEv2 uttrycker samma tvåstegsidé med annan mekanik, och det är i de skillnaderna migreringar misslyckas. Inget versionsnummer omvandlar den ena till den andra, och att kopiera de gamla alternativnamnen till en ny profil ger en klient som förhandlar och sedan inte autentiserar något.
Vad hybridläget gjorde inne i IKEv1
I en hybridprofil signerar svararen fas-ett-utbytet med sitt certifikat medan initiatören medvetet inte visar något. Identitetsbeviset är alltså asymmetriskt, och det var vad som lät en gateway behålla sin befintliga PKI medan användarna behöll sina katalogslösenord. När fas ett är klar kör XAuth som en begäran och ett svar som bär användarnamns- och lösenordsattribut inuti den nu krypterade ISAKMP-kanalen.
Notera var tilliten landar. Certifikatet svarar på vilken gateway klienten nådde; XAuth svarar på vilken användare som vill ha åtkomst. Ingen av dem ersätter den andra, och en klient som konfigurerats att acceptera vilket servercertifikat som helst har tyst kastat det första svaret. Etiketten hybrid används också för aggressive mode med fördelad nyckel plus XAuth, ett annat arrangemang med samma användarupplevelse, så läs profilen och inte namnet. Båda varianterna härstammar från utkast som aldrig blev standarder, och därför kan två leverantörer implementera hybridläget och inte interoperera med någon.
Hur IKEv2 når samma två bevis
IKEv2 delar arbetet mellan IKE_SA_INIT och IKE_AUTH. Det första utbytet förhandlar fram förslag och nycklar helt utan identiteter; det andra bär IDi, IDr och AUTH-nyttolasterna. Under EAP går initiatörens första AUTH-nyttolast ut tom, svararen autentiserar sig först med certifikat och signatur, och sedan körs EAP-samtalet inuti IKE_AUTH-meddelandena.
Mekanismen som gör detta säkert är nyckelmaterial. En lyckad EAP-metod exporterar en sessionsnyckel, och initiatörens slutliga AUTH-nyttolast beräknas från den, så användarens bevis och tunnelns nycklar binds samman. XAuth har ingen motsvarighet: dess attribut anländer efter fas ett och bidrar inte med något till nycklarna. Det gapet är precis vad IKEv2-ramverket designades för att stänga, och därför validerar en fungerande IKEv2-inloggning servercertifikatet innan den frågar efter något.
Den ordningen är också en användbar diagnos. När en klient klagar på inloggningsuppgifterna innan den har visat dig ett certifikat gör den inte alls något IKEv2 EAP-utbyte.
Håll tre identiteter åtskilda
En migrering går fel när tre identiteter kollapsar i ett enda fält. Det finns gatewayidentiteten som klienten validerar, oftast ett DNS-namn i certifikatets subject eller SAN. Det finns användaridentiteten som presenteras i EAP, kanske en domäninloggning, en adress eller en explicit EAP-identitetssträng. Och det finns auktoriseringskällan som mappar den användaren till nätverk och rutter.
strongSwans swanctl-syntax gör uppdelningen synlig: anslutningen sätter remote { auth = pubkey } för gatewayen och local { auth = eap-mschapv2 } för användaren, med EAP-identiteten buren separat.
När användaridentiteten i den nya profilen skiljer sig från de gamla XAuth-attributen, till exempel ett UPN i stället för ett kort namn, ser autentiseringsservern en okänd användare och felet ser ut som ett felaktigt lösenord. Kontrollera identitetssträngen innan du kontrollerar inloggningsuppgifterna.
Kartlägg alternativen och förvänta dig sedan fällorna
Mappningen är kort och varje rad har en fälla som först dyker upp vid autentiseringen.
| 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 de raderna är en enkel namnändring. Konfigurationsnyttolasten levererar adresser och resolvers via en typad attributlista, medan XAuths attributrymd var dess egen uppfinning; att behandla dem som utbytbara är hur en profil till slut ber om en inställning som gatewayen aldrig skickar.
Trafikväljare förtjänar sin egen varning. IKEv1 uttryckte intressant trafik via proxy-ID:n bundna till ett quick-mode-utbyte, medan IKEv2 förhandlar väljarna under IKE_AUTH och svararen får snäva in dem. En missanpassning ger en etablerad IKE SA utan child SA, som vissa klienter glatt visar som ansluten.
Behandla den gamla anslutningen som en gräns
RFC 9395 avskriver IKEv1, så en gammal hybridanslutning är en kompatibilitetsgräns med ett datum på, inte en grund. Kör båda profilerna sida vid sida under bytet, för testet som betyder något är inte om den nya profilen kommer upp utan om samma användare på samma enhet når samma resurser.
Håll certifikatvalideringen strikt hela vägen. När klienten slutar visa sitt eget certifikat är frestelsen att lätta på serverkontrollen tills handskakningen går igenom, och det byter den enda återstående bevisningen mot en grön ikon.
Skriv ned fyra saker innan du pensionerar den gamla profilen: EAP-metoden, identitetssträngen, auktoriseringskällan och datumet då supporten upphör.