IKEv2 NO_PROPOSAL_CHOSEN: dəstə hansı mərhələdə rədd edildi?

Logda NO_PROPOSAL_CHOSEN insanları əvvəlcədən paylaşılan açara yönləndirir və xəta dəyişiklikdən sonra da qalır. Bu heç vaxt etimad məlumatı problemi deyildi: qarşı tərəf həmin mübadilə üçün təqdim edilən hər təklifi rədd etdi, bu isə şəxsiyyət deyil, alqoritmlər barədə ifadədir. İlk faydalı sual hansı alqoritmi redaktə etmək deyil, hansı mübadilənin rədd edildiyidir. Hər hansı müqayisədən əvvəl buna cavab verin. Sonra təklif edilən tam dəstəni qarşı tərəfin icazə verdiyi tam dəstə ilə müqayisə edin.

Birinci: hansı mübadilə rədd edildi

IKEv2 iki növ assosiasiya üzrə danışıq aparır. IKE SA danışığın özünü qoruyur, CHILD SA isə trafiki qoruyur. Hər birinin öz təklif dəsti var və hər biri eyni bildirişlə uğursuz ola bilər. İlkin IKE danışığı zamanı rədd və CHILD danışığı zamanı rədd fərqli düzəlişlər tələb edir və adətən log mübadilənin adını bildirişdən bir-iki sətir yuxarıda göstərir. Bu iki sətri birlikdə oxuyun, əks halda səhv təklif siyahısını redaktə edəcəksiniz.

Bildiriş təkbaşına mübadiləni müəyyən etmir. Üstündəki sətir danışıq aparılan SA-nın adını çəkir və bu ad yoxlanmalı təklif siyahısına işarə edir.

Tam dəstələri müqayisə edin, ayrı açar sözləri deyil

Təklif bir birləşmədir: şifrələmə alqoritmi, bütövlük və ya AEAD, açar mübadiləsi qrupu və istənilən psevdo-təsadüfi funksiya. Yalnız şifrələmə adını müqayisə etmək adi səhvdir, çünki iki qarşı tərəf AES-256 barədə razılaşıb yenə də SHA-1 ilə SHA-256 arasında fikir ayrılığına düşə bilər. Uğursuz mərhələdə təklif edilən və icazə verilən dəstələri yan-yana yazın, sonra boş kəsişməni axtarın.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Həm də yoxlayın ki, hər iki tətbiq konfiqurasiya etdiyinizi dəstəkləyir. Başqa platformadan köçürülən ad sintaktik olaraq tanış görünə bilər halbuki plagin və ya tətbiq tamamilə yoxdur.

IKE dəsti və ESP dəsti fərqli obyektlərdir

IKE təklifini redaktə etmək rədd edilmiş CHILD təklifini düzəltməyəcək və əksi də doğrudur. strongSwan-da bunlar ayrı parametrlərdir, təxminən proposals = aes256-sha256-modp2048 IKE SA üçün və CHILD SA üçün ayrı ESP siyahısı. Uğursuz mübadiləyə uyğun siyahını dəyişin, sonra düzəlişin işlədiyini güman etmək əvəzinə logu yenidən oxuyun.

CHILD SA üçün müvafiq parametr ESP təklif siyahısıdır, IKE siyahısı deyil. IKE sətrini ora köçürmək yanlış obyekti təhlil edən və danışıq aparan konfiqurasiya yaradır.

Açar yeniləməsində uğursuz olan işlək tunel

Əgər tunel bir saat işləyib sonra uğursuz oldusa, ilkin danışıq problem deyil. Açar yeniləməsi fərqli şərtləri işə sala bilər: ilk mübadilədən sonra fərqli açar mübadiləsi qrupu, qarşı tərəflər arasında ömür uyğunsuzluğu və ya dəyişmiş cavab verən siyasəti. Yeniləmə vaxt damğasını və assosiasiya identifikatorlarını hər iki tərəfdən saxlayın. Bu naxış yeniləmədə təklif müqayisəsi tələb edir, daha uzun fasilə deyil. Fasilə dəyişikliyi simptomu gizlədir və uyğunsuzluğu yerində qoyur.

ipsec statusall hər assosiasiyanı və faktiki danışıq aparılmış alqoritmləri göstərir. Bu çıxış hansı siyahının istifadə edildiyini təsdiqləməyin ən sürətli yoludur və konfiqurasiya səhvini heç vaxt yenidən danışıq aparmayan köhnə tuneldən ayırır.

ipsec statusall | grep -E "IKE:|ESP:"

Kəsişmə seçin, sonra hər iki mərhələni təsdiqləyin

Administratorun hər iki qarşı tərəfin dəstəklədiyi sənədləşdirilmiş müasir kəsişməni seçməsini təmin edin və onu yazın. Xətanı hər köhnə alqoritmi aktivləşdirməklə və ya kimlik yoxlamasını söndürməklə həll etməyin, çünki heç biri rədd cavabından irəli gəlmir. Dəyişiklikdən sonra yeni bağlantı qurun və sonra açar yeniləməsini məcburi edin. Yalnız ilk bağlantı yeniləmə yolunun işlədiyini sübut etmir.

Qəbul edilmiş birləşməni firmware versiyaları ilə birlikdə saxlayın. Əgər növbəti xəta trafik seçicilərinə aiddirsə, onu ayrıca həll edin, çünki kriptoqrafiya barədə razılıq tunelin hansı alt şəbəkələri qoruduğu barədə heç nə demir. strongSwan təklif sənədləşməsi hər iki siyahının sintaksisini əhatə edir.