Çdo profil i vjetër VPN që kërkon fillimisht një certifikatë serveri dhe pastaj një emër përdoruesi mbart dy ngjarje autentikimi në një shkëmbim të vetëm, dhe ajo formë jeton më gjatë se protokolli që e solli. Modaliteti hibrid i IKEv1 u ndërtua pikërisht për këtë: porta dëshmon veten me një çelës publik ndërsa përdoruesi dëshmon veten më vonë përmes XAuth. IKEv2 shpreh të njëjtën ide dyhapësh me mekanizëm tjetër, dhe pikërisht në ato dallime dështojnë migrimet. Asnjë numër versioni nuk e kthen njërin në tjetrin, dhe kopjimi i emrave të vjetër të opsioneve në një profil të re jep një klient që negocion dhe pastaj nuk vërteton asgjë.

Çfarë bënte modaliteti hibrid brenda IKEv1

Në një profil hibrid pala përgjigjëse nënshkruan shkëmbimin e fazës së parë me certifikatën e vet, ndërsa iniciatori me qëllim nuk paraqet asnjë. Prandaj prova e identitetit është asimetrike, dhe kjo është ajo që lejoi një portë të mbante PKI-në ekzistuese ndërsa përdoruesit mbanin fjalëkalimet e drejtorisë. Kur faza e parë përfundon, XAuth ekzekutohet si një kërkesë dhe përgjigje që mbart atributet e emrit të përdoruesit dhe fjalëkalimit brenda kanalit ISAKMP tashmë të kriptuar.

Vini re ku zbret besimi. Certifikata përgjigjet se në cilën portë arriti klienti; XAuth përgjigjet se cili përdorues dëshiron akses. Asnjëra nuk e zëvendëson tjetrën, dhe një klient i konfiguruar të pranojë çdo certifikatë serveri e ka hedhur në heshtje përgjigjen e parë. Etiketa hibrid përdoret gjithashtu për modalitetin agresiv me çelës të parashpërndarë plus XAuth, një rregullim tjetër me të njëjtën përvojë përdoruesi, prandaj lexoni profilin dhe jo emrin. Të dy variantet vijnë nga skica që nuk u bënë kurrë standarde, dhe për këtë arsye dy prodhues mund të zbatojnë modalitetin hibrid dhe të mos ndërveprojnë me asnjë.

Si arrin IKEv2 në të njëjtat dy prova

IKEv2 e ndan punën midis IKE_SA_INIT dhe IKE_AUTH. Shkëmbimi i parë merr dakord për propozime dhe çelësa pa asnjë identitet; i dyti mbart IDi, IDr dhe ngarkesat AUTH. Nën EAP ngarkesa e parë AUTH e iniciatorit del bosh, përgjigjësi autentikohet i pari me certifikatën dhe nënshkrimin e vet, dhe pastaj biseda EAP zhvillohet brenda mesazheve IKE_AUTH.

Mekanizmi që e bën këtë të sigurt është materiali i çelësit. Një metodë EAP e suksesshme eksporton një çelës sesioni, dhe ngarkesa e fundit AUTH e iniciatorit llogaritet prej tij, kështu që prova e përdoruesit dhe çelësat e tunelit lidhen bashkë. XAuth nuk ka ekuivalent: atributet e tij vijnë pas fazës së parë dhe nuk kontribuojnë asgjë në çelësat. Pikërisht atë boshllëk u projektua të mbyllte korniza e IKEv2, dhe prandaj një hyrje funksionale në IKEv2 vërteton certifikatën e serverit para se të kërkojë çdo gjë.

Ky rend është gjithashtu një diagnozë e dobishme. Kur një klient ankohet për kredencialet para se t'ju ketë treguar një certifikatë, ai nuk po bën fare një shkëmbim EAP të IKEv2.

Mbani tre identitete të ndara

Një migrim shkon keq kur tre identitete shemben në një fushë. Ekziston identiteti i portës që klienti vërteton, zakonisht një emër DNS në subject ose SAN të certifikatës. Ekziston identiteti i përdoruesit i paraqitur në EAP, ndoshta një hyrje domeni, një adresë ose një varg identiteti EAP i qartë. Dhe ekziston burimi i autorizimit që e harton atë përdorues në rrjeta dhe rrugë.

Sintaksa swanctl e strongSwan e bën të dukshëm ndarjen: lidhja vendos remote { auth = pubkey } për portën dhe local { auth = eap-mschapv2 } për përdoruesin, ndërsa identiteti EAP bartet veç.

Kur identiteti i përdoruesit në profilin e re ndryshon nga atributet e vjetra XAuth, për shembull një UPN në vend të një emri të shkurtër, serveri i autentikimit sheh një përdorues të panjohur dhe dështimi duket si fjalëkalim i gabuar. Kontrolloni vargun e identitetit para se të kontrolloni kredencialet.

Hartoni opsionet dhe pastaj prisni kurthet

Hartëzimi është i shkurtër dhe çdo rresht ka një kurth që shfaqet vetëm në kohën e autentikimit.

Legacy hybrid elementIKEv2 equivalentWhere it bites
Gateway certificate, no client certificateResponder authenticated with pubkey, initiator with EAPThe server needs an EAP method configured, not just a certificate
XAuth username and passwordEAP-MSCHAPv2 or an inner methodPassword policy and account format differ from the old directory field
XAuth attribute repliesIKEv2 configuration payloadAttribute numbering is unrelated; nothing is renamed
Proxy IDs from quick modeTS_i and TS_r in IKE_AUTHNarrowing on the responder can leave an IKE SA with no child SA

Asnjë prej atyre rreshtave nuk është thjesht riemërtim. Ngarkesa e konfigurimit jep adresa dhe zgjidhës përmes një liste atributash të tipizuar, ndërsa hapësira e atributeve të XAuth ishte shpikja e vet; t'i trajtosh si të këmbyeshëm është mënyra se si një profil përfundon duke kërkuar një parametër që porta nuk do ta dërgojë kurrë.

Përzgjedhësit e trafikut meritojnë paralajmërimin e tyre. IKEv1 e shprehte trafikun me interes përmes identifikuesve proxy të lidhur me një shkëmbim quick mode, ndërsa IKEv2 i negocion përzgjedhësit gjatë IKE_AUTH dhe përgjigjësi mund t'i ngushtojë. Mospërputhja prodhon një IKE SA të vendosur pa child SA, të cilën disa klientë e shfaqin me kënaqësi si të lidhur.

Trajtojeni lidhjen e vjetër si kufi

RFC 9395 e shpall IKEv1 të vjetruar, prandaj një lidhje e vjetër hibrid është kufi përputhshmërie me datë, jo themel. Nisni të dy profilet krah për krah gjatë ndryshimit, sepse testi që ka rëndësi nuk është a ngrihet profili i re, por a arrin i njëjti përdorues në të njëjtën pajisje te të njëjtat burime.

Mbajeni të rreptë vërtetimin e certifikatës deri në fund. Pasi klienti ndalon së paraqituri certifikatën e vet, tundimi është të lehtësohet kontrolli i serverit derisa të përfundojë shtrëngimi i duarve, dhe kjo e ndërron provën e vetme që mbetet me një ikonë të gjelbër.

Shkruani katër gjëra para se ta pensiononi profilin e vjetër: metodën EAP, vargun e identitetit, burimin e autorizimit dhe datën kur mbaron mbështetja.

Artikuj të ngjashëm