Секој стар 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 идентитетски стринг. И туку е изворот на авторизација што го пресликува тој корисник на мрежи и рути.

Синтаксата swanctl на strongSwan ја прави поделбата видлива: врската поставува remote { auth = pubkey } за порталот и local { auth = eap-mschapv2 } за корисникот, а EAP идентитетот се носи одделно.

Кога идентитетот на корисникот во новиот профил се разликува од старите XAuth атрибути, на пример UPN наместо кратко име, серверот за автентикација гледа непознат корисник и дефектот изгледа како погрешна лозинка. Проверете го стрингот на идентитетот пред да ги проверите акредитивите.

Мапирајте ги опциите и потоа очекувајте ги стапиците

Мапирањето е кратко и секој ред има стапица што се појавува само при автентикација.

Legacy hybrid elementIKEv2 equivalentWhere it bites
Gateway certificate, no client certificateResponder authenticated with pubkey, initiator with EAPThe server needs an EAP method configured, not just a certificate
XAuth username and passwordEAP-MSCHAPv2 or an inner methodPassword policy and account format differ from the old directory field
XAuth attribute repliesIKEv2 configuration payloadAttribute numbering is unrelated; nothing is renamed
Proxy IDs from quick modeTS_i and TS_r in IKE_AUTHNarrowing 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 како застарен, така што старата хибридна врска е граница на компатибилност со датум, а не основа. Вртете ги двата профили паралелно за време на промената, бидејќи тестот што е важен не е дали новиот профил се крева, туку дали истиот корисник на истиот уред стигнува до истите ресурси.

Држете ја проверката на сертификатите строга до крај. Штом клиентот престане да го приложува својот сертификат, искушението е да ја олабавите проверката на серверот додека ракувањето не помине, а тоа го заменува единствениот преостанат доказ за зелена икона.

Запишете четири работи пред да го пензионирате стариот профил: EAP методот, стрингот на идентитетот, изворот на авторизација и датумот кога поддршката завршува.

Поврзани статии