IKEv1 гибридтік аутентификациясы IKEv2 пайдаланушы аутентификациясына қалай өтеді
Гибридтік режим шлюздің дәлелін пайдаланушының дәлелінен бөлді. IKEv2-ге көшу осы бөлуді сақтайды, бірақ алмасуды, EAP әдісін және сертификат тексерулерін өзгертеді.
Сервер сертификатын, содан кейін пайдаланушы атын сұрайтын әрбір ескі VPN профилі бір алмасуда екі аутентификация оқиғасын алып жүреді, және бұл пішін оны енгізген протоколдан ұзақ өмір сүреді. IKEv1 гибридтік режимі дәл осы үшін құрылған: шлюз өзін ашық кілтпен дәлелдейді, ал пайдаланушы өзін кейінірек XAuth арқылы дәлелдейді. IKEv2 сол екі қадамдық идеяны басқа механизммен білдіреді, және миграциялар дәл осы айырмашылықтарда сәтсіз аяқталады. Ешбір нұсқа нөмірі бірін екіншісіне айналдырмайды, ал ескі опция атауларын жаңа профильге көшіру келісім жасап, содан кейін ештеңені аутентификацияламайтын клиент береді.
Гибридтік режим IKEv1 ішінде не істеді
Гибридтік профильде жауап беруші бірінші фаза алмасуына өз сертификатымен қол қояды, ал бастаушы әдейі ештеңе ұсынбайды. Сондықтан жеке бас дәлелі асимметриялы, және бұл шлюзге қолданыстағы PKI-ді сақтап, пайдаланушыларға каталогтық құпиясөздерін сақтауға мүмкіндік берді. Бірінші фаза аяқталғаннан кейін XAuth қазір шифрланған ISAKMP арнасының ішінде пайдаланушы аты мен құпиясөз атрибуттарын алып жүретін сұраныс және жауап ретінде орындалады.
Сенім қайда түсетініне назар аударыңыз. Сертификат клиент қай шлюзге жеткенін жауап береді; XAuth қай пайдаланушы кіруге ниетті екенін жауап береді. Екеуі бірін-бірі алмастырмайды, және кез келген сервер сертификатын қабылдауға конфигурацияланған клиент бірінші жауапты үнсіз тастап кеткен. Гибридтік белгісі сонымен қатар алдын ала бөлісілген кілт пен XAuth қосылған агрессивті режим үшін де қолданылады, сол пайдаланушы тәжірибесі бар басқа орналасу, сондықтан атты емес, профильді оқыңыз. Екі нұсқа да ешқашан стандарт болмаған жобалардан шыққан, сондықтан екі өндіруші гибридтік режимді енгізіп, ешкіммен өзара әрекеттесе алмауы мүмкін.
IKEv2 сол екі дәлелге қалай жетеді
IKEv2 жұмысты IKE_SA_INIT пен IKE_AUTH арасында бөледі. Бірінші алмасу ұсыныстар мен кілттерді ешқандай жеке бассыз келіседі; екіншісі IDi, IDr және AUTH жүктемелерін алып жүреді. EAP астында бастаушының бірінші AUTH жүктемесі бос шығады, жауап беруші бірінші болып өз сертификаты мен қолтаңбасымен аутентификацияланады, содан кейін EAP әңгімесі IKE_AUTH хабарламаларының ішінде жүреді.
Мұны қауіпсіз ететін механизм — кілт материалы. Сәтті EAP әдісі сессия кілтін экспорттайды, және бастаушының соңғы AUTH жүктемесі одан есептеледі, сондықтан пайдаланушының дәлелі мен туннель кілттері байланысқан. XAuth-та балама жоқ: оның атрибуттары бірінші фазадан кейін келіп, кілттерге ештеңе қоспайды. Дәл осы олқылықты IKEv2 қаңқасы жабу үшін жасалған, және сондықтан жұмыс істейтін IKEv2 кіруі ештеңе сұрамас бұрын сервер сертификатын тексереді.
Бұл тәртіп те пайдалы диагностика. Клиент сізге сертификат көрсетпестен бұрын тіркелгі деректеріне шағымданса, ол мүлде IKEv2 EAP алмасуын жасамайды.
Үш жеке басты бөлек ұстаңыз
Үш жеке бас бір өріске бірігіп кетсе, миграция нашар болады. Клиент тексеретін шлюз жеке басы бар, әдетте сертификаттың subject немесе SAN ішіндегі DNS аты. EAP ішінде ұсынылатын пайдаланушы жеке басы бар, мүмкін домендік кіру, мекенжай немесе анық EAP жеке бас жолы. Және сол пайдаланушыны желілер мен маршруттарға байланыстыратын авторизация көзі бар.
strongSwan swanctl синтаксисі бөлуді көрнекі етеді: қосылым шлюз үшін remote { auth = pubkey } және пайдаланушы үшін local { auth = eap-mschapv2 } орнатады, EAP жеке басы бөлек алып жүріледі.
Жаңа профильдегі пайдаланушы жеке басы ескі XAuth атрибуттарынан өзгеше болса, мысалы қысқа аттың орнына UPN, аутентификация сервері белгісіз пайдаланушыны көреді және ақау қате құпиясөз сияқты көрінеді. Тіркелгі деректерін тексермес бұрын жеке бас жолын тексеріңіз.
Опцияларды картаға түсіріңіз, содан кейін тұзақтарды күтіңіз
Картаға түсіру қысқа және әр жолда тек аутентификация кезінде пайда болатын тұзақ бар.
| 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 |
Ол жолдардың ешқайсысы қарапайым атау ауыстыру емес. Конфигурация жүктемесі мекенжайлар мен резолверлерді типтелген атрибут тізімі арқылы жеткізеді, ал XAuth атрибут кеңістігі өзінің ойлап табысы болды; оларды алмастырылатын деп санау — профильдің шлюз ешқашан жібермейтін параметрді сұрап қалуының жолы.
Трафик селекторлары өз ескертуіне лайық. IKEv1 қызықты трафикті quick mode алмасуына байланған proxy ID арқылы білдірді, ал IKEv2 селекторларды IKE_AUTH кезінде келіседі және жауап беруші оларды тарылта алады. Сәйкессіздік child SA жоқ орнатылған IKE SA тудырады, оны кейбір клиенттер қуана қосылған деп көрсетеді.
Ескі қосылымды шекара ретінде қарастырыңыз
RFC 9395 IKEv1-ді ескірген деп жариялайды, сондықтан ескі гибридтік қосылым — күні бар үйлесімділік шекарасы, іргетас емес. Өзгеріс кезінде екі профильді қатар іске қосыңыз, өйткені маңызды сынақ — жаңа профиль көтеріле ме, әлде сол пайдаланушы сол құрылғыда сол ресурстарға жете ме.
Сертификат тексеруін соңына дейін қатаң ұстаңыз. Клиент өз сертификатын ұсынуды тоқтатқаннан кейін, handshake бітпейінше сервер тексеруін әлсірету азғырығы пайда болады, және бұл соңғы қалған дәлелді жасыл белгіге айырбастайды.
Ескі профильді жою алдында төрт нәрсені жазыңыз: EAP әдісін, жеке бас жолын, авторизация көзін және қолдау аяқталатын күнді.