Bir IKEv2 girişində iki kimlik: əvvəl maşın, sonra istifadəçi

Müştəri sertifikatı təsdiqlənir, ilk mübadilə tamamlanır və sonra bağlantı əlavə autentifikasiya raundu barədə xəta ilə dayanır. Sertifikat zəncirində heç nə səhv deyil və şəbəkədə heç nə dəyişməyib. Şlüz qoşulan tərəfdən ikinci sübut tələb etmək üçün konfiqurasiya edilib, müştəri isə heç vaxt onu göndərmir. Kimin nəyi, hansı sırada sübut etməsini qərar vermək bütün işdir və o, üzərində durduğunuz endpointdən siyasəti oxumaqla başlayır. Müxtəlif növdən iki sübutun sabit sırada olması qeyd qutusu deyil, dizayn qərarıdır.

Simptom: uğurlu ilk sübutdan sonra uğursuzluq

İlk mübadilə tamamlanır və jurnal sağlam görünür, ta ki şlüz EAP vasitəsilə istifadəçi kimliyi tələb edənə qədər. Sonra əl sıxma dayanır və ya əlavə raundu adlandıran protokol xətası qaytarır. Tamamilə etibarlı maşın sertifikatı etibarlılığı ilə heç bir əlaqəsi olmayan səbəbdən rədd edilir. Siyasət ikinci sübut istədi, müştərinin cavabı isə heç vaxt gəlmədi.

Həmin uğursuzluğun hər iki təsviri harada dayandığınızdan asılı olaraq düzgündür. Müştəri tərəfindən bu, etibarlı sertifikatı rədd edən server kimi görünür, server tərəfindən isə girişi tamamlaya bilməyən müştəri kimi. Eyni hadisə bir jurnalda etimad problemi, digərində qabiliyyət problemi kimi oxunur. Yalnız konfiqurasiya edilmiş siyasət hansının olduğunu deyir.

Uzantının nə əlavə etdiyi və nə etmədiyi

IKEv2 tək sessiya daxilində birdən çox autentifikasiya mübadiləsi aparmaq üçün uzantı daşıyır. RFC 4739 digər ardıcıllıqlarla yanaşı, sertifikat kimliyini sübut edən və sonra EAP vasitəsilə şəxsi autentifikasiya edən müştərini təsvir edir. Sənəd Eksperimentaldır, yəni heç bir tətbiq sizə bu funksiyanı borclu deyil. Qarşı tərəf onu razılaşdırana qədər dəstək barədə heç nə fərz etməyin.

Hər iki tərəf uzantını dəstəkləməli və mübadilə zamanı onunla razılaşmalıdır. İkinci raund üçün konfiqurasiya edilmiş şlüz müştərini onu icra etməyə məcbur edə bilməz, onu dəstəkləyən müştəri isə server istəməsə ondan istifadə etməyəcək. Bu asimmetriya uğursuzluğun niyə qabiliyyət barədə aydın bəyanat yerinə adətən timeout və ya protokol xətası kimi üzə çıxdığının səbəbidir. Bir tərəfin konfiqurasiyasını oxumaq sizə nə olacağının yarısını deyir.

Hər endpoint üçün bir sübut normal formadır və bu, həmin dizayn deyil. Şlüz sertifikatını təqdim edir, istifadəçi EAP ilə cavab verir və hər tərəf digərini düz bir dəfə autentifikasiya edib. Bu iki sübut qarşı-qarşıya endpointlərdən gəlir, ona görə heç biri maşın və onu istifadə edən şəxs barədə ayrıca heç nə demir.

EAP-TLS üçüncü formadır və o da bu deyil. Orada müştəri sertifikatı EAP metodu daxilində təqdim edilir, yəni müştəri yenə tək IKE autentifikasiyasını tamamlayır. Etimad məlumatları çoxraundlu hal ilə eyni görünə bilər, halbuki protokol iki yerinə bir raund daşıyır. EAP-TLS yerləşdirməsindən köçürülmüş dizaynın ikinci sübutun gözlənildiyi nöqtədə uğursuz olmasının səbəbi budur.

Eyni fayl şlüzdə fərqli oxunur

Eyni swanctl faylı harada işlədiyindən asılı olaraq fərqli oxunur və bu, insanları çaşdıran hissədir. Noutbukda şlüz qarşı tərəfdir, şlüzdə isə noutbuk qarşı tərəfdir, yəni local tərəfi mən kiməm, remote tərəfi isə kimləri qəbul edəcəyəm kimi yazın. local bloku bu endpointin özünü necə autentifikasiya etdiyini təsvir edir, remote bloku isə digər tərəfdən nə tələb etdiyini bildirir. Bloku iki fayl arasında köçürmək bir simvolu belə dəyişmədən mənasını tərsinə çevirir. İki faylı müqayisə etmək demək olar ki, heç nə demir, çünki eyni sözlər hər birində əks şeylər ifadə edir.

Bölmənin mövqeyi onun sırasını təyin edir, məgər raund nömrəsi onu üstələyirsə. Ona görə əlavə local və ya remote bölmələri alternativlər deyil, əlavə raundlar təsvir edir, və swanctl.conf istinadı sənədindəki açıq raund nömrəsi məhz bu sıralamanı qəsdən etmək üçün mövcuddur. O olmadan blokun yerini dəyişmək davranışı dəyişir. Buna görə də kağızda ekvivalent görünən iki konfiqurasiya əks sıralarla işləyə bilər.

Bu sıralama qaydası yadda saxlamağa dəyər uğursuzluq rejimini doğurur. İkinci remote bloku başqa məqbul variant deyil; o, ikinci tələbdir, buna görə ya/və ya kimi oxunan siyasət və-sonra kimi davranır. Şlüz siyasəti qeydiyyatdan keçmiş maşının sertifikatını qəbul edib sonra həmin istifadəçinin EAP mübadiləsini bu sırada tələb edə bilər.

Raundları müstəqil faktorlardan ayırın

İki raund avtomatik olaraq iki müstəqil faktor deyil. Sübutun təkrarlanması və ya iki etimad məlumatının eyni anbarda saxlanması dizaynın əlavə etməli olduğu gücü vermir. Müstəqillik sirlərin necə saxlanması və onları nəyin kompromisə uğratması xassəsidir, protokolun neçə mübadilə apardığı deyil. Raundları faktor kimi sayan dizayn əldə etdiyini şişirdir. Bu fərq xüsusilə uyğunluq sualı girişin faktiki olaraq neçə faktor istifadə etdiyini soruşanda vacibdir.

Maşın sertifikatı qəbul edilmiş açarına sahibliyi sübut edir, başqa heç nəyi. O, aparat attestasiyası deyil və cihaz sağlamlığı hesabatı deyil, ona görə postura məlumatı tələb edən siyasət fərqli mexanizmə ehtiyac duyur. subject sahəsi də etibar edə biləcəyiniz inventar etiketi deyil, çünki subject-i sertifikatı verən və ya qeydə alan seçir. Dizayn maşının sağlam olduğuna sübut tələb edirsə, həmin sübut maşını ölçən komponentdən gəlməlidir.

Hər raundun faktiki olaraq nəyi sübut etdiyini əlavə etməzdən əvvəl yazın. İki raund eyni şeyi iki dəfə sübut edirsə, ikincisi əminlik yerinə gecikmə və dəstək biletləri əlavə edir. Bu qeyd həm də əlavə raundun xərcini haqq edib-etmədiyi barədə mübahisəni dayandıran şeydir.

Cütləşmə qaydasını yazın və rəddləri sınayın

Hansı maşın kimliklərinin hansı insanlarla cütləşə biləcəyini qərar verin və qaydanı icra olunduğu yerə yazın. Yan-yana duran iki etibarlı etimad məlumatı cütləşmə barədə heç nə sübut etmir, çünki cütləşmə autentifikasiya nəticəsi deyil, avtorizasiya qərarıdır. Qeydiyyat yazıları və ya autentifikasiya backend-i təşkilatın istədiyi əlaqəni tətbiq etməlidir.

Sonra uğursuz olması lazım olanları sınayın: təsdiqlənməmiş maşında qəbul edilmiş istifadəçi, maşın etimad məlumatını daşıyan təsdiqlənməmiş istifadəçi və əlavə raundu icra edə bilməyən qarşı tərəf. Əgər hər üçü sakitcə eyni girişi alırsa, siyasət icra etmək yerinə niyyət təsvir edir. Bəyan edilmiş konfiqurasiyanı daemonun bildirdiyi ilə müqayisə edin, çünki heç vaxt uyğunlaşmayan bağlantı keçmiş qayda ilə eyni görünür:

swanctl --list-conns
swanctl --list-sas

Yalnız uğurlu girişi deyil, razılaşdırılmış raundları və nəticədə yaranan avtorizasiyanı yoxlayın. Və qısa yol kimi köhnə IKEv1 XAuth parametrlərinə əl atmayın: bağlantı uğurlu olana qədər tələb olunan raundu silmək yerinə protokolu, rolları, sıranı və müştərinin real davranışını uyğunlaşdırın. Uğursuz olan raundu silmək iki sübutlu dizaynın səssizcə heç kimin nəzərdən keçirmədiyi bir sübutlu dizayna çevrilmə üsuludur. Silməni dəyişiklik qeydində saxlayın.