Hoe IKEv1 syn hybride autentikaasje oergiet yn IKEv2-brûkersautentikaasje
De hybride modus skiede it bewiis fan de gateway fan dat fan de brûker. De oerstap nei IKEv2 hâldt dy skieding, mar feroaret de útwikseling, de EAP-metoade en de sertifikaatkontrôles.
Elk âld VPN-profyl dat earst in server-sertifikaat en dêrnei in brûkersnamme freget, draacht twa autentikaasjegebarternissen yn ien útwikseling, en dy foarm oerlibbet it protokul dat har ynfierde. De hybride modus fan IKEv1 is krekt hjirfoar boud: de gateway bewiist himsels mei in publike kaai wylst de brûker him letter fia XAuth bewiist. IKEv2 drukt itselde twastapidee út mei oare meganyk, en yn dy ferskillen mislearje migraasjes. Gjin ferzjenûmer ferbûget it iene yn it oare, en âlde opsjenammen nei in nij profyl kopiearje jout in klant dy't ûnderhannelt en dêrnei neat autentisearret.
Wat de hybride modus yn IKEv1 die
Yn in hybride profyl undertekenet de responder de útwikseling fan faze ien mei syn sertifikaat wylst de initiator opsetlik gjin sertifikaat oanbiedt. It identiteitsbewiis is dus asymmetrysk, en dat koe in gateway syn besteande PKI hâlde litte wylst brûkers harren mapwachtwurden hâlden. As faze ien klear is, rint XAuth as in fersyk en in antwurd dat brûkersnamme- en wachtwurdattributen yn it no fersifere ISAKMP-kanaal drage.
Tink derop wêr't it fertrouwen lânet. It sertifikaat antwurdet hokker gateway de klant berikt hat; XAuth antwurdet hokker brûker tagong wol. Gjin fan beide ferfangt de oare, en in klant dy't elk server-sertifikaat akseptearret, hat it earste antwurd stil weismiten. It label hybrid wurdt ek brûkt foar aggressive mode mei pre-shared key plus XAuth, in oare opstelling mei deselde brûkersûnderfining, dus lês it profyl en net de namme. Beide farianten komme út ûntwerpen dy't nea standert waarden, en dêrom kinne twa leveransiers hybride modus ymplementearje en mei gjinien ynteroperearje.
Hoe IKEv2 by deselde twa bewiizen komt
IKEv2 ferdielt it wurk oer IKE_SA_INIT en IKE_AUTH. De earste útwikseling ûnderhannelt foarstellen en kaaien sûnder hokker identiteit dan ek; de twadde draacht IDi, IDr en de AUTH-ladingen. Under EAP giet de earste AUTH-lading fan de initiator leech de doar út, de responder autentisearret him earst mei sertifikaat en hantekening, en dêrnei rint it EAP-petear binnen de IKE_AUTH-berjochten.
It meganyk dat dit feilich makket, is kaaimateriaal. In slagge EAP-metoade eksportearret in sesjekaai, en de lêste AUTH-lading fan de initiator wurdt dêrút berekkene, sadat it bewiis fan de brûker en de kaaien fan de tunnel oan elkoar bûn binne. XAuth hat gjin ekwivalint: syn attributen komme nei faze ien en drage neat by oan de kaaien. Krekt dy kleau woe it IKEv2-ramt tichtsje, en dêrom falt in wurkjende IKEv2-oanmelding it server-sertifikaat ôf foardat it eat freget.
Dizze oarder is ek in nuttige diagnoaze. As in klant oer oanmeldgegevens kleit foardat er jo in sertifikaat sjen litten hat, docht er hielendal gjin IKEv2 EAP-útwikseling.
Hâld trije identiteiten skieden
In migraasje rint mis as trije identiteiten yn ien fjild yninoar sakje. Der is de gateway-identiteit dy't de klant falidearret, meastentiids in DNS-namme yn it subject of SAN fan it sertifikaat. Der is de brûkersidentiteit dy't yn EAP oanbean wurdt, miskien in domeinoanmelding, in adres of in eksplisite EAP-identiteitsstring. En der is de autorisaasjeboarne dy't dy brûker op netwurken en rûtes ôfbyldet.
De swanctl-syntaksis fan strongSwan makket de skieding sichtber: de ferbining set remote { auth = pubkey } foar de gateway en local { auth = eap-mschapv2 } foar de brûker, mei de EAP-identiteit apart droegen.
As de brûkersidentiteit yn it nije profyl ferskilt fan de âlde XAuth-attributen, bygelyks in UPN ynstee fan in koarte namme, sjocht de autentikaasjeserver in ûnbekende brûker en liket de flater op in ferkeard wachtwurd. Kontrolearje de identiteitsstring foardat jo de oanmeldgegevens kontrolearje.
Yntekene de opsjes en ferwachtsje dan de strikken
De ynkaartbringing is koart en elke rige hat in strik dy't pas by autentikaasje opkomt.
| 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 |
Gjin fan dy rigen is in gewoane omneaming. De konfiguraasjelading leveret adressen en resolvers fia in typearre attributenlist, wylst XAuth syn attributromte in eigen útfining wie; se as útwikselber behannelje is hoe't in profyl úteinlik om in ynstelling freget dy't de gateway nea stjoere sil.
Ferkeursselekteurs fertsjinje har eigen warskôging. IKEv1 drukte nijsgjirrich ferkear út fia proxy-ID's dy't oan in quick-mode-útwikseling bûn wiene, wylst IKEv2 de selekteurs by IKE_AUTH ûnderhannelt en de responder se ferneare mei. In mismatch leveret in festige IKE SA sûnder child SA, dy't guon klanten fleurich as ferbûn toane.
Behannel de âlde ferbining as in grins
RFC 9395 ferklearret IKEv1 ferâldere, dus in âlde hybride ferbining is in kompatibiliteitsgrins mei in datum, gjin fûnemint. Lit beide profilen njonken elkoar rinne by de oerstap, want de test dy't telt is net oft it nije profyl opkomt, mar oft deselde brûker op itselde apparaat deselde boarnen berikt.
Hâld sertifikaatfalidaasje strang fan begjin oant ein. Sadree't de klant syn eigen sertifikaat net mear oanbiedt, is de ferlieding grut om de serverkontrôle te fersêftsjen oant de handshake trochkomt, en dat ruilet it iennichste oerbleaune bewiis foar in grien byldsje.
Skriuw fjouwer dingen op foardat jo it âlde profyl ôfskaffe: de EAP-metoade, de identiteitsstring, de autorisaasjeboarne en de datum wêrop stipe einiget.