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 ыкмасын, инсандык сабын, авторизация булагын жана колдоо бүткөн күндү.