Как хибридното удостоверяване в 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 изразяваше интересния трафик чрез proxy ID, вързани към обмен quick mode, докато IKEv2 договаря селекторите по време на IKE_AUTH и отговарящата страна може да ги стесни. Несъответствието дава установен IKE SA без child SA, който някои клиенти весело показват като свързан.
Третирайте старата връзка като граница
RFC 9395 обявява IKEv1 за остарял, така че старата хибридна връзка е граница на съвместимост с дата, а не фундамент. Пускайте двата профила паралелно по време на промяната, защото важният тест не е дали новият профил се вдига, а дали същият потребител на същото устройство стига до същите ресурси.
Дръжте проверката на сертификатите строга докрай. Щом клиентът спре да представя собствения си сертификат, изкушението е да разхлабите проверката на сървъра, докато ръкостискането мине, а това разменя единственото останало доказателство срещу зелена икона.
Запишете четири неща, преди да пенсионирате стария профил: EAP метода, низа на самоличността, източника на оторизация и датата, на която поддръжката свършва.