Як гібрыдная аўтэнтыфікацыя 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 правярае сертыфікат сервера, перш чым нешта запытаць.
Гэты парадак — яшчэ і карысная дыягностыка. Калі кліент скардзіцца на ўліковыя даныя, не паказаўшы вам сертыфікат, ён зусім не выконвае абмен EAP у IKEv2.
Трымайце тры ідэнтычнасці асобна
Міграцыя ідзе не так, калі тры ідэнтычнасці зліваюцца ў адно поле. Ёсць ідэнтычнасць шлюза, якую правярае кліент, звычайна імя DNS у subject або SAN сертыфіката. Ёсць ідэнтычнасць карыстальніка, пададзеная ў EAP, — магчыма, даменны ўваход, адрас або яўны радок ідэнтычнасці EAP. І ёсць крыніца аўтарызацыі, што суадносіць гэтага карыстальніка з сеткамі і маршрутамі.
Сінтаксіс swanctl у strongSwan робіць раздзяленне бачным: злучэнне задае 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, тады як IKEv2 узгадняе селектары падчас IKE_AUTH, і адказнік можа іх звузіць. Разыходжанне дае ўсталяваны IKE SA без child SA, які некаторыя кліенты радасна паказваюць як падключаны.
Лічыце старое злучэнне мяжой
RFC 9395 абвяшчае IKEv1 састарэлым, таму старое гібрыднае злучэнне — мяжа сумяшчальнасці з датай, а не фундамент. Запускайце абодва профілі паралельна на час пераходу, бо важны тэст — не ці ўздымаецца новы профіль, а ці трапляе той самы карыстальнік на той самай прыладзе да тых самых рэсурсаў.
Трымайце праверку сертыфікатаў строгай да канца. Як толькі кліент перастае падаваць уласны сертыфікат, узнікае спакуса аслабіць праверку сервера, пакуль рукапоціск не пройдзе, а гэта мяняе адзіны астатні доказ на зялёную пазнаку.
Запішыце чатыры рэчы, перш чым выводзіць стары профіль: метад EAP, радок ідэнтычнасці, крыніцу аўтарызацыі і дату заканчэння падтрымкі.