IKEv2 sertifikatı və SAN: identifikasiya yoxlaması niyə uğursuz olur

Sertifikatınız etibarlı CA-ya zəncirlənir, tarixlər qaydasındadır, amma peer yenə də 1-ci fazanı şəxsiyyət xətası ilə tamamlamaqdan imtina edir. Əlçatanlıq və etibarlı imza IKEv2 müştərisinin yoxladığının yalnız yarısıdır. Digər yarısı gözlədiyi şəxsiyyətin sertifikatda düzgün sahədə görünüb-görünməməsidir və bu gözləntini sertifikatın fayl adı deyil, profil müəyyən edir.

Simptom həmişə eyni formadadır

Bir bağlantı profili host adından IP ünvanına dəyişdirilir və ya DNS adı daşıyan sertifikatdan yalnız ünvanlar daşıyan sertifikata yenilənir və tunnel danışıqları dayandırır. Şəbəkə yolunda heç nə dəyişməyib. Müştəri peer-ə çatır, sertifikat alır və peer şəxsiyyətini rədd edir, çünki gözləməsi deyilən identifikator qəbul etdiyi sahədə təmsil olunmur. Yeniləmələr adi səbəbdir, çünki əvəz edən sertifikat çox vaxt əvəz etdiyindən fərqli şablondan gəlir.

Sonra hər iki tərəf faydasız bir şey qeyd edir, buna görə nasazlıq adətən sertifikat problemi kimi bildirilir. Müştəri jurnalı istədiyi şəxsiyyətin adını çəkə bilər və bu ad sizin axtardığınız ipucudur, bitmə tarixi deyil.

Yalnız dəyəri deyil, identifikator növünü uyğunlaşdırın

dNSName SAN və iPAddress SAN fərqli uyğunlaşdırma qaydaları olan fərqli sahələrdir, ona görə 203.0.113.10-u DNS sətri kimi daşıyan sertifikat IP şəxsiyyəti gözləyən müştərini qane etmir. Müasir yoxlayıcılar ümumi adı əsasən nəzərə almır, ona görə sertifikat detallarındakı dostyana etiket nəyin uyğunlaşacağı barədə heç nə sübut etmir. Problemsizlik axtarışı zamanı host adı ünvanla əvəz olunubsa, yoxlayana qədər gözlənilən şəxsiyyətin onunla birlikdə köçdüyünü fərz edin. Profildəki sətri SAN-dakı sətirlə hərf-hərf müqayisə edin, çünki sondakı nöqtə və ya təsadüfi boşluq kifayətdir.

Joker simvollar yalnız DNS üçün rahatlıqdır və öz uyğunlaşdırma qaydalarına tabedir, bu da IP əsaslı profilin onlara heç vaxt güvənməməsinin başqa səbəbidir.

Hər müştərinin gözləntini harada saxladığını tapın

strongSwan-da sertifikatla müqayisə edilən dəyər peer şəxsiyyəti parametrindən gəlir: klassik konfiqurasiyada rightid, swanctl-də uzaq bağlantı bölməsinin id sahəsi. Apple IKEv2 uyğunluğu sənədi burada faydalıdır, çünki profil əsaslı müştərinin istifadə etdiyi şəxsiyyət konvensiyalarını açıqlayır və həmin konvensiyalar şəbəkədə təsadüfi görünən uyğunsuzluq sinfini izah edir.

Apple konfiqurasiya profilləri uzaq identifikator sahəsi daşıyır və oradakı dəyər müştərinin yoxladığı şeydir, bağlantı parametrlərindəki server ünvanı deyil. Windows və cihaz müştərilərinin hər birinin öz sahəsi və öz standart dəyəri var və standart dəyər çox vaxt yazdığınız ünvanı izləyir. İki sahə ziddiyyət təşkil edəndə müştərinin həqiqətən oxuduğu sahə qalib gəlir və bu, nadir hallarda redaktə etdiyiniz sahə olur.

Profili və ya sertifikatı qəsdən düzəldin

Hər şeyi dəyişməzdən əvvəl peer sertifikatını təsdiqlənmiş alətlərlə yoxlayın və SAN girişlərini növləri ilə sadalayın. Bu yoxlama nə şəxsi açar, nə də yükləmə tələb edir və məsələni saniyələr içində həll edir. Yerləşdirmə bir DNS şəxsiyyəti nəzərdə tutursa, sertifikat onu dNSName girişi kimi daşımalıdır, ünvan nəzərdə tutursa, sertifikat məhz həmin ünvan üçün iPAddress girişinə ehtiyac duyur.

Sertifikat səhvdirsə, operatora konkret gözlənilən identifikatorla düzəldilmiş sertifikat üçün müraciət edin. Profil səhvdirsə, profili düzəldin və sertifikata toxunmayın. Şəxsiyyət yoxlamasını söndürmək xətanı yox edir və tunnelin nəzərdə tutduğunuz peer ilə danışdığını təsdiqləyən yoxlamanı aradan qaldırır.

Gözlənilən şəxsiyyəti hər müştəri platforması üzrə sənədləşdirin, çünki bir müştərinin avtomatik çıxardığı dəyər digərində açıq şəkildə göstərilməli ola bilər.

Yeniləmə sorğusuna dörd fakt verin

Gözlənilən identifikatoru və növünü, cari sertifikatın həqiqətən daşıdığı SAN girişlərini, yoxlamanı edən müştəri və versiyanı, dəqiq xəta mətnini yazın. Bu dörd sətirdən qurulan yeniləmə sorğusu ilk dəfə düzgün sertifikat alır, eyni tanış fayl adı ilə başqa birini yox.