XAuth və OTP ilə IKEv1: hər sorğu nə istəyir

IKEv1 PSK, XAuth və OTP ilə mürəkkəb bir parol istəmir. O, tərəflər arasında paylaşılan açarı, istifadəçi mübadiləsini və backendin necə soruşacağına qərar verdiyi ikinci faktoru qat-qat düzür. Hər qatın öz sahibi və öz xəta mesajı var. Onları qarışdırmaq insanları birdəfəlik kodu qrup sirrini saxlayan sahəyə yenidən yazmağa vadar edir.

Başqa müştəri quraşdırmadan və ya etimad məlumatını sıfırlamadan əvvəl hər sorğunu onu verən qatla uyğunlaşdırın.

Üç sirr, üç sahib

İlkin paylaşılan açar tərəf münasibətinə aiddir və hər iki ucu idarə edən tərəfindən bir dəfə qurulur. İstifadəçi etimad məlumatı autentifikasiya backendinə aiddir və hər girişdə yoxlanılır. İkinci faktor hər cəhddə cavabı dəyişən token sisteminə aiddir. Heç biri digərini əvəz etmir və onları bir parol kimi qəbul edən quraşdırma heç kimin sənədləşdirmədiyi qatda uğursuz olur.

Üç sütun yazın: sahib, ömür və hər birinin yaratdığı xəta mesajı. Həmin cədvəl diaqnostika alətidir, müştərinin sahə adları isə deyil.

PSK: şəxs deyil, tərəf

İlkin paylaşılan açar bu köhnə düzülüşdə şlüz cütünü autentifikasiya edir, ona görə istifadəçi girişi onu heç vaxt əvəz etmir. O həm də sorğu yerinə ümumi razılaşma xətası yaradan şəkildə səhv olma ehtimalı ən yüksək dəyərdir. Tunel hər hansı istifadəçi sorğusundan əvvəl uğursuz olursa, şübhəlilər açar və ya təkliflərdir.

İstifadəçi etimad məlumatı birinci fazanın uğursuzluğunu düzəldə bilməz. Onu dəyişmək təhlükəsiz dəyişə biləcəyiniz yeganə etimad məlumatını israf edir və yanlış nəzəriyyəni gücləndirir.

XAuth: köhnə istifadəçi mübadiləsi

XAuth IKEv1 tərəf autentifikasiyasının üstünə istifadəçi autentifikasiyası mübadiləsi əlavə edir və hansı backendin onu yoxlayacağına şlüz qərar verir. Həmin backenddən asılı olaraq mübadilə kataloq parolu, RADIUS etimad məlumatı və ya token cavabı qəbul edə bilər. XAuth sözü etimad məlumatının növünü deyil, mübadilənin daşıyıcısını adlandırır.

Şlüz profilinin hansı backendə işarə etdiyini yoxlayın. Bu, istifadəçidən nə soruşulacağını və parol sıfırlamasının həqiqətən nəyi dəyişdiyini göstərir və heç biri müştəri profilində görünmür.

OTP: backend nə istəsə

Bəzi quraşdırmalar paroldan sonra ayrıca birdəfəlik kod soruşur, digərləri isə sənədləşdirilmiş ayırıcı ilə birləşdirilmiş giriş formatı müəyyən edir. İkisi də mövcuddur və hansının olacağına qarşınızdakı profil qərar verir. Başqa bir saytda işlədiyi üçün birləşmə uydurmaq qeydiyyat tokenini yandırmağın ən geniş yayılmış yoludur. Şlüzün öz sənədləri bunu həll edən yeganə mənbədir.

Sənədləşdirilmiş formatı şlüzün təklif etdiyi mübadiləni tamamlaya bilən müştəri ilə istifadə edin.

Müştəri sərhədi harada kəsir

Fortinet bildirir ki, FortiClient 7.4.4 və sonrakı versiyalar IPsec VPN-lər üçün IKEv1-i artıq dəstəkləmir; bu, universal ləğv deyil, məhsul və versiya sərhədidir, FortiClient uyğunluq qeydi bunu qeyd edir. Digər müştərilər də bir-birini əvəz etmir: OpenConnect və openfortivpn konkret şlüz protokolları danışır, ixtiyari IKEv1 profilləri deyil. Quraşdırılmış müştərinin IKE versiyasını, PSK rejimini, XAuth dəstəyini və qarşılıqlı əlaqə modelini ayrı-ayrılıqda yoxlayın. Fərqli üsulla qoşulan müştəri ilkin tələbi sübut etməmişdir.

IKEv1 köhnəlmişdir, ona görə dəstəklənməyən köhnə müştəri üzərində qurulan yeni tətbiq qısa ömürlü həlldir. Şlüz sahibindən dəstəklənən miqrasiya yolu istəyin, o cümlədən ikinci faktorun orada necə idarə olunacağını.

Faktoru söndürmədən diaqnostika

Jurnalda mərhələləri ayırın: tərəf razılaşması, istifadəçi mübadiləsi, ikinci faktorun nəticəsi, sonra ünvan və marşrut təyini. Kodu hər sahədə sınamaq əvəzinə komponenti və mərhələni qeyd edin. Test keçsin deyə faktoru söndürmək quraşdırma haqqında heç nə sübut etməyən tunel yaradır.

Qeydiyyat sirlərini və paylaşılan açarı təşkilatın prosesinə uyğun qorunan yaddaşda saxlayın. Daimi faylda saxlanan birdəfəlik kod artıq faktor olmaqdan çıxmış faktordur.