Kā IKEv1 hibrīdā autentifikācija pāriet IKEv2 lietotāja autentifikācijā
Hibrīdrežīms atdalīja vārtejas pierādījumu no lietotāja pierādījuma. Pāreja uz IKEv2 saglabā šo atdalījumu, bet maina apmaiņu, EAP metodi un sertifikāta pārbaudes.
Katrs vecais VPN profils, kas vispirms prasa servera sertifikātu un pēc tam lietotājvārdu, vienā apmaiņā nes divus autentifikācijas notikumus, un šī forma pārdzīvo protokolu, kas to ieviesa. IKEv1 hibrīdrežīms tika būvēts tieši tam: vārteja pierāda sevi ar publisko atslēgu, bet lietotājs pierāda sevi vēlāk ar XAuth. IKEv2 izsaka to pašu divpakāpju ideju ar citādu mehānismu, un tieši šajās atšķirībās migrācijas cieš neveiksmi. Neviens versijas numurs nepārvērš vienu otrā, un veco opciju nosaukumu kopēšana jaunā profilā dod klientu, kas vienojas un pēc tam neko neautentificē.
Ko hibrīdrežīms darīja IKEv1 iekšienē
Hibrīdprofīlā atbildētājs paraksta pirmās fāzes apmaiņu ar savu sertifikātu, kamēr iniciators apzināti neuzrāda nevienu. Identitātes pierādījums tādējādi ir asimetrisks, un tas ļāva vārtejai saglabāt esošo PKI, kamēr lietotāji saglabāja savas direktorija paroles. Kad pirmā fāze ir pabeigta, XAuth darbojas kā pieprasījums un atbilde, kas pārnēsā lietotājvārda un paroles atribūtus tagad šifrētajā ISAKMP kanālā.
Ievērojiet, kur nonāk uzticēšanās. Sertifikāts atbild, kuru vārteju klients sasniedza; XAuth atbild, kurš lietotājs vēlas piekļuvi. Neviens neaizstāj otru, un klients, kas konfigurēts pieņemt jebkuru servera sertifikātu, klusi ir atmetis pirmo atbildi. Etiķete hibrīds tiek lietota arī agresīvajam režīmam ar iepriekš kopīgu atslēgu un XAuth, cita konfigurācija ar tādu pašu lietotāja pieredzi, tāpēc lasiet profilu, nevis nosaukumu. Abi varianti nāk no melnrakstiem, kas tā arī nekļuva par standartiem, tāpēc divi ražotāji var ieviest hibrīdrežīmu un ne savstarpēji sadarboties ne ar vienu.
Kā IKEv2 nonāk pie tiem pašiem diviem pierādījumiem
IKEv2 sadala darbu starp IKE_SA_INIT un IKE_AUTH. Pirmā apmaiņa saskaņo priekšlikumus un atslēgas pilnīgi bez identitātēm; otrā pārnēsā IDi, IDr un AUTH kravas. Saskaņā ar EAP iniciatora pirmā AUTH krava iznāk tukša, atbildētājs vispirms autentificējas ar savu sertifikātu un parakstu, un pēc tam EAP saruna norisinās IKE_AUTH ziņojumos.
Mehānisms, kas to padara drošu, ir atslēgu materiāls. Veiksmīga EAP metode eksportē sesijas atslēgu, un iniciatora galīgā AUTH krava tiek aprēķināta no tās, tāpēc lietotāja pierādījums un tuneļa atslēgas tiek saistītas. XAuth nav ekvivalenta: tā atribūti ierodas pēc pirmās fāzes un neko nepievieno atslēgām. Tieši šo plaisu IKEv2 ietvars tika projektēts aizvērt, un tāpēc strādājoša IKEv2 pieteikšanās validē servera sertifikātu, pirms kaut ko prasa.
Šī secība ir arī noderīga diagnostika. Kad klients sūdzas par akreditācijas datiem, pirms tas jums ir parādījis sertifikātu, tas nemaz neveic IKEv2 EAP apmaiņu.
Turiet trīs identitātes atsevišķi
Migrācija nogājusi greizi, kad trīs identitātes saplūst vienā laukā. Ir vārtejas identitāte, ko klients validē, parasti DNS nosaukums sertifikāta subject vai SAN laukā. Ir lietotāja identitāte, kas tiek uzrādīta EAP, varbūt domēna pieteikšanās, adrese vai skaidra EAP identitātes virkne. Un ir autorizācijas avots, kas šo lietotāju saista ar tīkliem un maršrutiem.
strongSwan swanctl sintakse padara atdalījumu redzamu: savienojums iestata remote { auth = pubkey } vārtejai un local { auth = eap-mschapv2 } lietotājam, un EAP identitāte tiek pārnēsāta atsevišķi.
Kad lietotāja identitāte jaunajā profilā atšķiras no vecajiem XAuth atribūtiem, piemēram, UPN īsa vārda vietā, autentifikācijas serveris redz nezināmu lietotāju, un kļūme izskatās pēc nepareizas paroles. Pārbaudiet identitātes virkni, pirms pārbaudāt akreditācijas datus.
Kartējiet opcijas un tad gaidiet slazdus
Kartējums ir īss, un katrai rindai ir slazds, kas parādās tikai autentifikācijas laikā.
| 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 |
Neviena no šīm rindām nav vienkārša pārdēvēšana. Konfigurācijas krava piegādā adreses un atrisinātājus caur tipizētu atribūtu sarakstu, kamēr XAuth atribūtu telpa bija pašu izgudrojums; uzskatīt tos par aizvietojamiem ir ceļš, kā profils beigās prasa iestatījumu, ko vārteja nekad nesūtīs.
Satiksmes selektori pelnījuši savu brīdinājumu. IKEv1 izteica interesējošo satiksmi ar proxy ID, kas saistīti ar quick mode apmaiņu, kamēr IKEv2 pārrunā selektorus IKE_AUTH laikā un atbildētājs tos drīkst sašaurināt. Neatbilstība rada izveidotu IKE SA bez child SA, ko daži klienti priecīgi rāda kā savienotu.
Uztveriet veco savienojumu kā robežu
RFC 9395 atzīst IKEv1 par novecojušu, tāpēc vecs hibrīdsavienojums ir saderības robeža ar datumu, nevis pamats. Darbiniet abus profilus līdzās pārejas laikā, jo svarīgais tests nav tas, vai jaunais profils paceļas, bet vai tas pats lietotājs tajā pašā ierīcē sasniedz tos pašus resursus.
Saglabājiet stingru sertifikātu validāciju visu laiku. Kad klients pārstāj uzrādīt savu sertifikātu, kārdinājums ir mīkstināt servera pārbaudi, līdz rokasspiediens pabeidzas, un tas iemaina vienīgo atlikušo pierādījumu pret zaļu ikonu.
Pierakstiet četras lietas, pirms atteikties no vecā profila: EAP metodi, identitātes virkni, autorizācijas avotu un datumu, kad atbalsts beidzas.