Hoe IKEv1 hybride authenticatie overgaat in IKEv2-gebruikersauthenticatie
De hybride modus scheidde het bewijs van de gateway van dat van de gebruiker. De overstap naar IKEv2 houdt die scheiding, maar verandert de uitwisseling, de EAP-methode en de certificaatcontroles.
Elk oud VPN-profiel dat eerst een servercertificaat en daarna een gebruikersnaam vraagt, draagt twee authenticatiegebeurtenissen in één uitwisseling, en die vorm overleeft het protocol dat haar introduceerde. De IKEv1 hybride modus is precies hiervoor gebouwd: de gateway bewijst zich met een publieke sleutel terwijl de gebruiker zich later via XAuth bewijst. IKEv2 drukt hetzelfde tweestapsidee uit met andere mechaniek, en in die verschillen mislukken migraties. Geen enkel versienummer zet het ene om in het andere, en oude optienamen naar een nieuw profiel kopiëren levert een client op die onderhandelt en daarna niets authenticeert.
Wat de hybride modus in IKEv1 deed
In een hybride profiel ondertekent de responder de fase-een-uitwisseling met zijn certificaat, terwijl de initiator bewust geen certificaat toont. Het identiteitsbewijs is dus asymmetrisch, en dat stelde een gateway in staat zijn bestaande PKI te houden terwijl gebruikers hun directorywachtwoorden hielden. Zodra fase een klaar is, draait XAuth als verzoek en antwoord die gebruikersnaam- en wachtwoordattributen vervoeren binnen het nu versleutelde ISAKMP-kanaal.
Let op waar het vertrouwen belandt. Het certificaat beantwoordt welke gateway de client heeft bereikt; XAuth beantwoordt welke gebruiker toegang wil. Geen van beide vervangt de ander, en een client die elk servercertificaat accepteert, heeft het eerste antwoord stil weggegooid. Het etiket hybride wordt ook gebruikt voor aggressive mode met pre-shared key plus XAuth, een andere opzet met dezelfde gebruikerservaring, dus lees het profiel en niet de naam. Beide varianten komen uit ontwerpen die nooit standaard werden, en daarom kunnen twee leveranciers hybride modus implementeren en met geen enkele interopereren.
Hoe IKEv2 bij dezelfde twee bewijzen komt
IKEv2 verdeelt het werk over IKE_SA_INIT en IKE_AUTH. De eerste uitwisseling spreekt voorstellen en sleutels af zonder enige identiteit; de tweede draagt IDi, IDr en de AUTH-payloads. Onder EAP gaat de eerste AUTH-payload van de initiator leeg de deur uit, authenticeert de responder zich eerst met certificaat en handtekening, en loopt daarna het EAP-gesprek binnen de IKE_AUTH-berichten.
Het mechanisme dat dit veilig maakt, is sleutelmateriaal. Een geslaagde EAP-methode exporteert een sessiesleutel, en de laatste AUTH-payload van de initiator wordt daaruit berekend, zodat het bewijs van de gebruiker en de sleutels van de tunnel aan elkaar gebonden zijn. XAuth heeft geen equivalent: de attributen komen na fase een en dragen niets aan de sleutels bij. Precies die kloof wilde het IKEv2-raamwerk dichten, en daarom valideert een werkende IKEv2-login het servercertificaat voordat er iets gevraagd wordt.
Deze volgorde is ook een nuttige diagnose. Wanneer een client over inloggegevens klaagt voordat hij u een certificaat heeft getoond, doet hij helemaal geen IKEv2 EAP-uitwisseling.
Houd drie identiteiten gescheiden
Een migratie gaat mis wanneer drie identiteiten in één veld samenvallen. Er is de gateway-identiteit die de client valideert, meestal een DNS-naam in het subject of SAN van het certificaat. Er is de gebruikersidentiteit die in EAP wordt gepresenteerd, misschien een domeinlogin, een adres of een expliciete EAP-identiteitsstring. En er is de autorisatiebron die die gebruiker aan netwerken en routes koppelt.
De swanctl-syntaxis van strongSwan maakt de splitsing zichtbaar: de verbinding zet remote { auth = pubkey } voor de gateway en local { auth = eap-mschapv2 } voor de gebruiker, met de EAP-identiteit apart vervoerd.
Wanneer de gebruikersidentiteit in het nieuwe profiel afwijkt van de oude XAuth-attributen, bijvoorbeeld een UPN in plaats van een korte naam, ziet de authenticatieserver een onbekende gebruiker en lijkt de storing op een verkeerd wachtwoord. Controleer de identiteitsstring voordat u de inloggegevens controleert.
Breng de opties in kaart en verwacht de valkuilen
De mapping is kort en elke rij heeft een valkuil die pas bij de authenticatie opduikt.
| 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 |
Geen van die rijen is een simpele hernoeming. De configuratie-payload levert adressen en resolvers via een getypeerde attributenlijst, terwijl de attribuutruimte van XAuth een eigen uitvinding was; ze als uitwisselbaar behandelen is hoe een profiel uiteindelijk om een instelling vraagt die de gateway nooit zal sturen.
Traffic selectors verdienen hun eigen waarschuwing. IKEv1 drukte interessant verkeer uit via proxy-ID's die aan een quick-mode-uitwisseling gebonden waren, terwijl IKEv2 de selectors tijdens IKE_AUTH onderhandelt en de responder ze mag vernauwen. Een mismatch levert een gevestigde IKE SA zonder child SA, die sommige clients vrolijk als verbonden tonen.
Behandel de oude verbinding als een grens
RFC 9395 verklaart IKEv1 verouderd, dus een oude hybride verbinding is een compatibiliteitsgrens met een datum, geen fundament. Draai beide profielen naast elkaar tijdens de overgang, want de test die telt is niet of het nieuwe profiel opkomt, maar of dezelfde gebruiker op hetzelfde apparaat dezelfde bronnen bereikt.
Houd certificaatvalidatie streng van begin tot eind. Zodra de client zijn eigen certificaat niet meer toont, is de verleiding groot de servercontrole te versoepelen tot de handshake rondkomt, en dat ruilt het enige overgebleven bewijs in voor een groen pictogram.
Schrijf vier dingen op voordat u het oude profiel uitfaseert: de EAP-methode, de identiteitsstring, de autorisatiebron en de datum waarop de ondersteuning stopt.