IKEv1 hibrid autentifikasiyası IKEv2 istifadəçi autentifikasiyasına necə keçir
Hibrid rejim şlüzün sübutunu istifadəçinin sübutundan ayırırdı. IKEv2-yə keçid bu bölgünü saxlayır, lakin mübadiləni, EAP metodunu və sertifikat yoxlamalarını dəyişir.
Əvvəlcə server sertifikatı, sonra istifadəçi adı tələb edən hər köhnə VPN profili bir mübadilədə iki autentifikasiya hadisəsi daşıyır və bu forma onu gətirən protokoldan uzun yaşayır. IKEv1 hibrid rejimi məhz bunun üçün qurulub: şlüz özünü açıq açarla sübut edir, istifadəçi isə özünü sonra XAuth vasitəsilə sübut edir. IKEv2 eyni iki addımlı ideyanı başqa mexanizmlə ifadə edir və miqrasiyalar məhz bu fərqlərdə uğursuz olur. Heç bir versiya nömrəsi birini digərinə çevirmir və köhnə seçim adlarını yeni profilə köçürmək razılaşan, sonra heç nəyi autentifikasiya etməyən klient verir.
Hibrid rejim IKEv1 içində nə edirdi
Hibrid profildə cavab verən tərəf birinci faza mübadiləsini öz sertifikatı ilə imzalayır, təşəbbüskar isə qəsdən heç birini təqdim etmir. Buna görə şəxsiyyət sübutu asimmetrikdir və bu, şlüzə mövcud PKI-ni saxlamağa, istifadəçilərə isə kataloq parollarını saxlamağa imkan verdi. Birinci faza bitdikdən sonra XAuth artıq şifrələnmiş ISAKMP kanalı daxilində istifadəçi adı və parol atributlarını daşıyan sorğu və cavab kimi işləyir.
Etibarın hara düşdüyünə diqqət edin. Sertifikat klientin hansı şlüzə çatdığını cavablandırır; XAuth hansı istifadəçinin giriş istədiyini cavablandırır. Heç biri digərini əvəz etmir və hər hansı server sertifikatını qəbul etməyə qurulmuş klient birinci cavabı səssizcə atmış olur. Hibrid etiketi həmçinin əvvəlcədən paylaşılmış açar üstəgəl XAuth ilə aqressiv rejim üçün də istifadə olunur, eyni istifadəçi təcrübəsi olan başqa düzən, ona görə adı deyil, profili oxuyun. Hər iki variant heç vaxt standart olmayan layihələrdən gəlir və buna görə iki istehsalçı hibrid rejimi tətbiq edib heç biri ilə qarşılıqlı işləyə bilməz.
IKEv2 eyni iki sübuta necə çatır
IKEv2 işi IKE_SA_INIT və IKE_AUTH arasında bölür. Birinci mübadilə heç bir şəxsiyyət olmadan təkliflər və açarlar barədə razılaşır; ikincisi IDi, IDr və AUTH yüklərini daşıyır. EAP altında təşəbbüskarın ilk AUTH yükü boş çıxır, cavab verən ilk öncə öz sertifikatı və imzası ilə autentifikasiya olunur, sonra EAP söhbəti IKE_AUTH mesajlarının içində gedir.
Bunu təhlükəsiz edən mexanizm açar materialıdır. Uğurlu EAP metodu sessiya açarı ixrac edir və təşəbbüskarın son AUTH yükü ondan hesablanır, beləliklə istifadəçinin sübutu və tunelin açarları bir-birinə bağlanır. XAuth-un ekvivalenti yoxdur: atributları birinci fazadan sonra gəlir və açarlara heç nə qatmır. IKEv2 çərçivəsi məhz bu boşluğu bağlamaq üçün dizayn edilib və buna görə işləyən IKEv2 girişi nəyisə soruşmazdan əvvəl server sertifikatını yoxlayır.
Bu sıra həm də faydalı diaqnostikadır. Klient sizə sertifikat göstərməmişdən əvvəl giriş məlumatlarından şikayət edirsə, o, ümumiyyətlə, IKEv2 EAP mübadiləsi etmir.
Üç şəxsiyyəti ayrı saxlayın
Miqrasiya üç şəxsiyyət bir sahədə birləşəndə pis gedir. Klientin yoxladığı şlüz şəxsiyyəti var, adətən sertifikatın subject və ya SAN sahəsində DNS adı. EAP-da təqdim olunan istifadəçi şəxsiyyəti var, bəlkə domen girişi, ünvan və ya açıq EAP şəxsiyyət sətri. Və o istifadəçini şəbəkələrə və marşrutlara bağlayan avtorizasiya mənbəyi var.
strongSwan-ın swanctl sintaksisi bölgünü görünən edir: bağlantı şlüz üçün remote { auth = pubkey } və istifadəçi üçün local { auth = eap-mschapv2 } təyin edir, EAP şəxsiyyəti isə ayrıca daşınır.
Yeni profildə istifadəçi şəxsiyyəti köhnə XAuth atributlarından fərqlənirsə, məsələn qısa ad yerinə UPN, autentifikasiya serveri naməlum istifadəçi görür və nasazlıq yanlış parol kimi görünür. Giriş məlumatlarını yoxlamazdan əvvəl şəxsiyyət sətrini yoxlayın.
Seçimləri xəritələyin, sonra tələləri gözləyin
Xəritələmə qısadır və hər sətirdə yalnız autentifikasiya anında görünən tələ var.
| 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 |
O sətirlərin heç biri sadə ad dəyişməsi deyil. Konfiqurasiya yükü ünvanları və həllediciləri tipləşdirilmiş atribut siyahısı ilə çatdırır, XAuth-un atribut sahəsi isə öz ixtirası idi; onları dəyişdirilə bilən saymaq profilin şlüzün heç vaxt göndərməyəcəyi parametri istəməsi ilə nəticələnmənin yoludur.
Trafik seçiciləri öz xəbərdarlığına layiqdir. IKEv1 maraqlı trafiki quick mode mübadiləsinə bağlı proxy ID-lərlə ifadə edirdi, IKEv2 isə seçiciləri IKE_AUTH zamanı razılaşdırır və cavab verən onları daralda bilər. Uyğunsuzluq child SA-sı olmayan qurulmuş IKE SA yaradır, bəzi klientlər bunu sevinclə qoşulmuş kimi göstərir.
Köhnə bağlantıya sərhəd kimi baxın
RFC 9395 IKEv1-i köhnəlmiş elan edir, yəni köhnə hibrid bağlantı üzərində tarix olan uyğunluq sərhədidir, təməl deyil. Dəyişiklik zamanı hər iki profili yan-yana işlədin, çünki vacib olan test yeni profilin qalxıb-qalxmaması deyil, eyni istifadəçinin eyni cihazda eyni resurslara çatıb-çatmamasıdır.
Sertifikat yoxlamasını axıra qədər ciddi saxlayın. Klient öz sertifikatını təqdim etməyi dayandıran kimi handshake bitənə qədər server yoxlamasını yumşaltmaq vəsvəsəsi yaranır və bu, qalan yeganə sübutu yaşıl işarə ilə dəyişir.
Köhnə profili ləğv etməzdən əvvəl dörd şey yazın: EAP metodu, şəxsiyyət sətri, avtorizasiya mənbəyi və dəstəyin bitdiyi tarix.