Kiel hibrida aŭtentigo de IKEv1 transiras al uzanta aŭtentigo de IKEv2
La hibrida reĝimo apartigis la pruvon de la pordego disde la pruvo de la uzanto. La transiro al IKEv2 konservas tiun apartigon sed ŝanĝas la interŝanĝon, la EAP-metodon kaj la kontrolojn de la atestilo.
Ĉiu malnova VPN-profilo, kiu unue petas servilan atestilon kaj poste uzantnomon, portas du aŭtentigajn eventojn en unu interŝanĝo, kaj tiu formo vivas pli longe ol la protokolo, kiu enkondukis ĝin. La hibrida reĝimo de IKEv1 estis konstruita ĝuste por tio: la pordego pruvas sin per publika ŝlosilo dum la uzanto pruvas sin poste per XAuth. IKEv2 esprimas la saman duŝtupan ideon per alia mekanismo, kaj ĝuste en tiuj diferencoj la migradoj malsukcesas. Neniu versia numero transformas unu en la alian, kaj kopii la malnovajn opciajn nomojn en novan profilon donas klienton, kiu intertraktas kaj poste aŭtentigas nenion.
Kion la hibrida reĝimo faris ene de IKEv1
En hibrida profilo la responda flanko subskribas la interŝanĝon de la unua fazo per sia atestilo dum la iniciatinto intence prezentas neniun. La identeca pruvo do estas nesimetria, kaj tio ebligis al pordego konservi sian ekzistantan PKI dum la uzantoj konservis siajn dosierujajn pasvortojn. Kiam la unua fazo finiĝas, XAuth funkcias kiel peto kaj respondo, kiuj portas la atributojn de uzantnomo kaj pasvorto ene de la jam ĉifrita ISAKMP-kanalo.
Rimarku, kie la fido alteriĝas. La atestilo respondas, al kiu pordego la kliento alvenis; XAuth respondas, kiu uzanto volas aliron. Neniu anstataŭas la alian, kaj kliento agordita akcepti ajnan servilan atestilon silente forĵetis la unuan respondon. La etikedo hibrida ankaŭ uziĝas por la agresa reĝimo kun antaŭe dividita ŝlosilo plus XAuth, alia aranĝo kun la sama uzanta sperto, do legu la profilon kaj ne la nomon. Ambaŭ variantoj venas de projektoj, kiuj neniam fariĝis normoj, kaj tial du fabrikantoj povas realigi la hibridan reĝimon kaj ne interagi kun iu ajn.
Kiel IKEv2 atingas la samajn du pruvojn
IKEv2 dividas la laboron inter IKE_SA_INIT kaj IKE_AUTH. La unua interŝanĝo interkonsentas proponojn kaj ŝlosilojn tute sen identecoj; la dua portas IDi, IDr kaj la AUTH-ŝarĝojn. Sub EAP la unua AUTH-ŝarĝo de la iniciatinto eliras malplena, la responda flanko aŭtentigas sin unue per sia atestilo kaj sia subskribo, kaj poste la EAP-interparolo daŭras ene de la IKE_AUTH-mesaĝoj.
La mekanismo, kiu igas tion sekura, estas ŝlosila materialo. Sukcesa EAP-metodo eksportas seanŝlosilon, kaj la fina AUTH-ŝarĝo de la iniciatinto estas kalkulita el ĝi, do la pruvo de la uzanto kaj la ŝlosiloj de la tunelo estas ligitaj. XAuth havas neniun ekvivalenton: ĝiaj atributoj alvenas post la unua fazo kaj kontribuas nenion al la ŝlosiloj. Ĝuste tiun breĉon la kadro de IKEv2 estis desegnita fermi, kaj tial funkcianta IKEv2-ensaluto validigas la servilan atestilon antaŭ ol peti ion ajn.
Tiu ordo ankaŭ estas utila diagnozo. Kiam kliento plendas pri akreditaĵoj antaŭ ol montri al vi atestilon, ĝi tute ne faras EAP-interŝanĝon de IKEv2.
Tenu tri identecojn aparte
Migrado misiras, kiam tri identecoj kolapsas en unu kampon. Estas la identeco de la pordego, kiun la kliento validigas, kutime DNS-nomo en la subject aŭ SAN de la atestilo. Estas la uzanta identeco prezentata en EAP, eble domajna ensaluto, adreso aŭ eksplicita EAP-identeca ĉeno. Kaj estas la fonto de rajtigo, kiu mapas tiun uzanton al retoj kaj itineroj.
La sintakso swanctl de strongSwan igas la apartigon videbla: la konekto agordas remote { auth = pubkey } por la pordego kaj local { auth = eap-mschapv2 } por la uzanto, dum la EAP-identeco estas portata aparte.
Kiam la uzanta identeco en la nova profilo diferencas de la malnovaj XAuth-atributoj, ekzemple UPN anstataŭ mallonga nomo, la aŭtentiga servilo vidas nekonatan uzanton kaj la fiasko aspektas kiel malĝusta pasvorto. Kontrolu la identecan ĉenon antaŭ ol kontroli la akreditaĵojn.
Mapu la opciojn kaj poste atendu la kaptilojn
La mapado estas mallonga kaj ĉiu vico havas kaptilon, kiu aperas nur dum aŭtentigo.
| 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 |
Neniu el tiuj vicoj estas nura renomado. La agorda ŝarĝo liveras adresojn kaj solvantojn per tipigita atributlisto, dum la atributspaco de XAuth estis ĝia propra invento; trakti ilin kiel interŝanĝeblaj estas la vojo, per kiu profilo finas petante agordon, kiun la pordego neniam sendos.
La trafikselektiloj meritas sian propran averton. IKEv1 esprimis la interesan trafikon per prokuraj IDoj ligitaj al la interŝanĝo quick mode, dum IKEv2 intertraktas la selektilojn dum IKE_AUTH kaj la responda flanko povas mallarĝigi ilin. Malkongruo produktas establitajn IKE SA sen child SA, kiun iuj klientoj ĝoje montras kiel konektita.
Traktu la malnovan konekton kiel limon
RFC 9395 deklaras IKEv1 malaktuala, do malnova hibrida konekto estas kongrueca limo kun dato, ne fundamento. Rulu ambaŭ profilojn flanke al flanke dum la ŝanĝo, ĉar la grava provo ne estas, ĉu la nova profilo supreniras, sed ĉu la sama uzanto sur la sama aparato atingas la samajn rimedojn.
Tenu la atestilan validigon strikta ĝis la fino. Tuj kiam la kliento ĉesas prezenti sian propran atestilon, la tento estas malpezigi la servilan kontrolon ĝis la manpremo finiĝos, kaj tio interŝanĝas la solan restantan pruvon kontraŭ verda piktogramo.
Skribu kvar aferojn antaŭ ol emeritigi la malnovan profilon: la EAP-metodon, la identecan ĉenon, la fonton de rajtigo kaj la daton, kiam la subteno finiĝas.