Како се хибридна аутентификација 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 размену.
Држите три идентитета одвојено
Миграција крене по злу када се три идентитета слеју у једно поље. Ту је идентитет приступника који клијент проверава, обично DNS име у subject или SAN сертификата. Ту је идентитет корисника представљен у 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 је изражавао занимљив саобраћај преко proxy ID-а везаних за quick mode размену, док IKEv2 преговара селекторе током IKE_AUTH и одговарач их може сузити. Несклад ствара успостављен IKE SA без child SA, који неки клијенти весело приказују као повезан.
Третирајте стару везу као границу
RFC 9395 означава IKEv1 застарелим, па је стара хибридна веза граница компатибилности с датумом, а не темељ. Покрените оба профила упоредо током промене, јер тест који је битан није да ли се нови профил диже, него да ли исти корисник на истом уређају долази до истих ресурса.
Држите проверу сертификата строгом цело време. Када клијент престане да представља властити сертификат, искушење је да ублажите проверу сервера док се handshake не заврши, а то мења једини преостали доказ за зелену икону.
Запишите четири ствари пре него што умирујете стари профил: EAP методу, идентитетски низ, извор ауторизације и датум када подршка престаје.