Kuidas IKEv1 hübriidautentimine läheb üle IKEv2 kasutajaautentimiseks
Hübriidrežiim eraldas lüüsi tõestuse kasutaja tõestusest. Üleminek IKEv2-le säilitab selle eralduse, kuid muudab vahetust, EAP-meetodit ja sertifikaadi kontrolle.
Iga vana VPN-profiil, mis kõigepealt küsib serveri sertifikaati ja seejärel kasutajanime, kannab ühes vahetuses kahte autentimissündmust, ja see vorm elab kauem kui selle toonud protokoll. IKEv1 hübriidrežiim ehitati täpselt selleks: lüüs tõestab end avaliku võtmega, kasutaja tõestab end hiljem XAuthi kaudu. IKEv2 väljendab sama kaheetapilist ideed teise mehhanismiga, ja just neis erinevustes migratsioonid ebaõnnestuvad. Ükski versiooninumber ei muuda üht teiseks, ja vanade valikunimede uude profiili kopeerimine annab kliendi, mis läbiräägib ja seejärel ei autendi midagi.
Mida hübriidrežiim IKEv1 sees tegi
Hübriidprofiilis allkirjastab vastav pool esimese faasi vahetuse oma sertifikaadiga, samal ajal kui algataja teadlikult ühtegi ei esita. Identiteedi tõestus on seega asümmeetriline, ja just see võimaldas lüüsil säilitada olemasolev PKI, samal ajal kui kasutajad säilitasid oma kataloogi paroolid. Kui esimene faas on lõppenud, töötab XAuth päringu ja vastusena, mis kannavad kasutajanime ja parooli atribuute juba krüpteeritud ISAKMP kanalis.
Pange tähele, kuhu usaldus maandub. Sertifikaat vastab, millise lüüsini klient jõudis; XAuth vastab, milline kasutaja soovib juurdepääsu. Kumbki ei asenda teist, ja klient, mis on seatud aktsepteerima ükskõik millist serveri sertifikaati, on vaikselt esimese vastuse ära visanud. Hübriidi silti kasutatakse ka agressiivse režiimi jaoks, kus on eelnevalt jagatud võti pluss XAuth, mis on teine paigutus sama kasutajakogemusega, seega lugege profiili, mitte nime. Mõlemad variandid pärinevad kavanditest, mis ei saanud kunagi standarditeks, ja seetõttu võivad kaks tootjat hübriidrežiimi rakendada ja mitte ühegi teisega koostalitleda.
Kuidas IKEv2 jõuab samade kahe tõestuseni
IKEv2 jagab töö IKE_SA_INIT ja IKE_AUTH vahel. Esimene vahetus lepib kokku ettepanekud ja võtmed täiesti ilma identiteetideta; teine kannab IDi, IDr ja AUTH-koormused. EAP all läheb algataja esimene AUTH-koormus välja tühjana, vastav pool autendib end kõigepealt oma sertifikaadi ja allkirjaga ning seejärel kulgeb EAP-vestlus IKE_AUTH sõnumite sees.
Mehhanism, mis teeb selle turvaliseks, on võtmematerjal. Õnnestunud EAP-meetod ekspordib seansi võtme ja algataja viimane AUTH-koormus arvutatakse sellest, nii et kasutaja tõestus ja tunnelivõtmed on omavahel seotud. XAuthil pole vastet: selle atribuudid saabuvad pärast esimest faasi ega anna võtmetele midagi. Just selle lõhe pidi IKEv2 raamistik sulgema, ja seetõttu valideerib töötav IKEv2 sisselogimine serveri sertifikaadi enne, kui midagi küsib.
See järjekord on ka kasulik diagnoos. Kui klient kaebab mandaatide üle enne, kui on teile sertifikaati näidanud, ei tee ta üldse IKEv2 EAP-vahetust.
Hoidke kolm identiteeti eraldi
Migratsioon läheb valesti, kui kolm identiteeti kukuvad kokku ühte välja. On lüüsi identiteet, mida klient valideerib, tavaliselt DNS-nimi sertifikaadi subject või SAN väljal. On EAP-s esitatav kasutaja identiteet, võib-olla domeeni sisselogimine, aadress või selgesõnaline EAP-identiteedistring. Ja on autoriseerimisallikas, mis kaardistab selle kasutaja võrkudele ja marsruutidele.
strongSwani swanctl süntaks teeb eralduse nähtavaks: ühendus seab lüüsile remote { auth = pubkey } ja kasutajale local { auth = eap-mschapv2 }, kusjuures EAP-identiteeti kantakse eraldi.
Kui uues profiilis erineb kasutaja identiteet vanadest XAuth-atribuutidest, näiteks UPN lühikese nime asemel, näeb autentimisserver tundmatut kasutajat ja tõrge näeb välja nagu vale parool. Kontrollige identiteedistringi enne mandaatide kontrollimist.
Kaardistage valikud ja seejärel oodake lõkse
Kaardistus on lühike ja igas reas on lõks, mis ilmub ainult autentimise hetkel.
| 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 |
Ükski neist ridadest pole lihtsalt ümbernimetamine. Konfiguratsioonikoormus toimetab aadressid ja resolverid tüpiseeritud atribuudiloendi kaudu, samal ajal kui XAuthi atribuudiruum oli tema enda leiutis; nende käsitlemine vahetatavatena on tee, millel profiil lõpuks küsib seadet, mida lüüs kunagi ei saada.
Liiklusvalijad väärivad oma hoiatust. IKEv1 väljendas huvipakkuvat liiklust quick mode'i vahetusega seotud puhverserveri ID-de kaudu, samal ajal kui IKEv2 peab valijate üle läbirääkimisi IKE_AUTH ajal ja vastav pool võib neid kitsendada. Sobimatus tekitab loodud IKE SA ilma child SA-ta, mida mõned kliendid näitavad rõõmsalt ühendatuna.
Käsitlege vana ühendust piirina
RFC 9395 kuulutab IKEv1 aegunuks, seega on vana hübriidühendus kuupäevaga ühilduvuspiir, mitte alus. Käivitage mõlemad profiilid muudatuse ajal kõrvuti, sest tähtis test pole see, kas uus profiil tõuseb, vaid see, kas sama kasutaja samas seadmes jõuab samade ressurssideni.
Hoidke sertifikaatide valideerimine lõpuni rangena. Niipea kui klient lõpetab oma sertifikaadi esitamise, on kiusatus lõdvendada serveri kontrolli, kuni käepigistus lõpeb, ja see vahetab ainsa allesjäänud tõestuse rohelise ikooni vastu.
Kirjutage üles neli asja enne vana profiili kasutuselt kõrvaldamist: EAP-meetod, identiteedistring, autoriseerimisallikas ja kuupäev, mil tugi lõpeb.