Kaip IKEv1 hibridinė autentifikacija pereina į IKEv2 naudotojo autentifikaciją
Hibridinis režimas skyrė tinklų sietuvos įrodymą nuo naudotojo įrodymo. Perėjimas prie IKEv2 išlaiko tą atskyrimą, bet keičia apsikeitimą, EAP metodą ir sertifikato patikras.
Kiekvienas senas VPN profilis, kuris pirmiausia prašo serverio sertifikato, o paskui naudotojo vardo, neša du autentifikacijos įvykius viename apsikeitime, ir ta forma pergyvena ją įvedusį protokolą. IKEv1 hibridinis režimas buvo sukurtas būtent tam: tinklų sietuva įrodo save viešuoju raktu, o naudotojas įrodo save vėliau per XAuth. IKEv2 išreiškia tą pačią dviejų žingsnių idėją kitokiu mechanizmu, ir būtent tuose skirtumuose migracijos žlunga. Joks versijos numeris nepaverčia vieno kitu, o senų parinkčių pavadinimų kopijavimas į naują profilį duoda klientą, kuris susiderina ir tada nieko neautentifikuoja.
Ką hibridinis režimas veikė IKEv1 viduje
Hibridiniame profilyje atsakiklis pasirašo pirmos fazės apsikeitimą savo sertifikatu, o iniciatorius sąmoningai jo nepateikia. Identiteto įrodymas todėl yra asimetrinis, ir tai leido tinklų sietuvai išlaikyti esamą PKI, o naudotojams – savo katalogo slaptažodžius. Kai pirma fazė baigiama, XAuth veikia kaip užklausa ir atsakymas, kurie perduoda naudotojo vardo ir slaptažodžio atributus jau šifruotame ISAKMP kanale.
Atkreipkite dėmesį, kur atsiduria pasitikėjimas. Sertifikatas atsako, kurią tinklų sietuvą klientas pasiekė; XAuth atsako, kuris naudotojas nori prieigos. Nė vienas nepakeičia kito, o klientas, sukonfigūruotas priimti bet kokį serverio sertifikatą, tyliai atmetė pirmąjį atsakymą. Etiketė hibridinis taip pat naudojama agresyviam režimui su iš anksto bendru raktu ir XAuth – kita tvarka su ta pačia naudotojo patirtimi, todėl skaitykite profilį, o ne pavadinimą. Abu variantai kilo iš projektų, kurie taip ir netapo standartais, todėl du gamintojai gali įgyvendinti hibridinį režimą ir nesuderinamai veikti su nė vienu.
Kaip IKEv2 pasiekia tuos pačius du įrodymus
IKEv2 padalija darbą tarp IKE_SA_INIT ir IKE_AUTH. Pirmasis apsikeitimas suderina pasiūlymus ir raktus visiškai be identitetų; antrasis perduoda IDi, IDr ir AUTH naudingąsias apkrovas. Pagal EAP pirmoji iniciatoriaus AUTH apkrova išeina tuščia, atsakiklis pirmiausia autentifikuojasi savo sertifikatu ir parašu, o paskui EAP pokalbis vyksta IKE_AUTH pranešimuose.
Mechanizmas, kuris tai daro saugų, yra raktinė medžiaga. Sėkmingas EAP metodas eksportuoja sesijos raktą, ir galutinė iniciatoriaus AUTH apkrova apskaičiuojama iš jo, taigi naudotojo įrodymas ir tunelio raktai susiejami. XAuth neturi atitikmens: jo atributai atkeliauja po pirmos fazės ir nieko neprideda prie raktų. Būtent tą spragą IKEv2 sistema ir buvo sukurta uždaryti, todėl veikiantis IKEv2 prisijungimas patikrina serverio sertifikatą prieš ko nors prašydamas.
Ši tvarka taip pat yra naudinga diagnostika. Kai klientas skundžiasi dėl prisijungimo duomenų, dar nepademonstravęs sertifikato, jis visai neatlieka IKEv2 EAP apsikeitimo.
Laikykite tris tapatybes atskirai
Migracija nepavyksta, kai trys tapatybės sueina į vieną lauką. Yra tinklų sietuvos tapatybė, kurią klientas patikrina, dažniausiai DNS vardas sertifikato subject arba SAN lauke. Yra naudotojo tapatybė, pateikiama EAP, galbūt domeno prisijungimas, adresas arba aiški EAP tapatybės eilutė. Ir yra autorizacijos šaltinis, kuris susieja tą naudotoją su tinklais ir maršrutais.
strongSwan swanctl sintaksė padaro atskyrimą matomą: jungtis nustato remote { auth = pubkey } tinklų sietuvai ir local { auth = eap-mschapv2 } naudotojui, o EAP tapatybė perduodama atskirai.
Kai naudotojo tapatybė naujame profilyje skiriasi nuo senų XAuth atributų, pavyzdžiui, UPN vietoje trumpo vardo, autentifikacijos serveris mato nežinomą naudotoją, o gedimas atrodo kaip neteisingas slaptažodis. Patikrinkite tapatybės eilutę prieš tikrindami prisijungimo duomenis.
Susiekite parinktis ir tikėkitės spąstų
Susiejimas trumpas, ir kiekviena eilutė turi spąstus, kurie pasirodo tik autentifikacijos metu.
| 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 |
Nė viena iš tų eilučių nėra paprastas pervadinimas. Konfigūracijos apkrova perduoda adresus ir rezolverius per tipizuotą atributų sąrašą, o XAuth atributų erdvė buvo jos pačios išradimas; laikyti juos sukeičiamais yra būdas, kuriuo profilis ima prašyti nustatymo, kurio tinklų sietuva niekada nesiųs.
Srauto selektoriai nusipelno atskiro įspėjimo. IKEv1 išreikšdavo įdomų srautą proxy ID, susietais su quick mode apsikeitimu, o IKEv2 derasi dėl selektorių IKE_AUTH metu ir atsakiklis gali juos susiaurinti. Nesutapimas sukuria nustatytą IKE SA be child SA, kurią kai kurie klientai linksmai rodo kaip prisijungusią.
Traktuokite seną jungtį kaip ribą
RFC 9395 panaikina IKEv1, tad sena hibridinė jungtis yra suderinamumo riba su data, o ne pamatas. Keiskite abu profilius lygiagrečiai, nes svarbus testas yra ne tai, ar naujas profilis pakyla, o ar tas pats naudotojas tame pačiame įrenginyje pasiekia tuos pačius išteklius.
Išlaikykite griežtą sertifikatų patikrą visą laiką. Kai klientas nustoja pateikti savo sertifikatą, kyla pagunda sušvelninti serverio patikrą, kol rankos paspaudimas praeis, ir taip vienintelis likęs įrodymas iškeičiamas į žalią piktogramą.
Užsirašykite keturis dalykus prieš atsisakydami seno profilio: EAP metodą, tapatybės eilutę, autorizacijos šaltinį ir datą, kada palaikymas baigiasi.