IKEv2-də ölü həmkar aşkarlanması tətbiqinizi yoxlamır

IKEv2 canlılıq yoxlaması bir sual verir: digər həmkar qorunan idarəetmə əlaqəsində hələ də cavab verirmi. O, daxili tətbiqin sağlam olub-olmadığını, şlüzün arxasında marşrutun olub-olmadığını və ya gəzintinin sürətli görünüb-görünmədiyini ölçmür. Yoxlama keçə bilər, halbuki tunelin arxasındakı hər faydalı şey uğursuz olur.

Taymeri dəyişməzdən əvvəl iki növ sübutu ayrı-ayrılıqda oxuyun.

Canlılıq yoxlaması əslində nə soruşur

Canlılıq mübadiləsi qurulmuş IKE təhlükəsizlik assosiasiyasının içində göndərilir və müəyyən edilmiş pəncərə daxilində cavab gözləyir. Uğur o deməkdir ki, həmkarın IKE tətbiqi hələ də oradadır və hələ də danışmağa hazırdır. Bu, trafiki daşıyan uşaq təhlükəsizlik assosiasiyaları haqqında heç nə demir, şlüzün o tayındakı marşrutlaşdırma haqqında heç nə, və tuneli açdığınız xidmət haqqında heç nə. Bunlar üç ayrı sual və üç ayrı nasazlıq rejimidir.

Bu fərq sessiya səssizləşəndə hara baxacağınızı müəyyən edir. Məlumat yolu pozulmuş halda cavab verməyə davam edən həmkar siyasətə, marşrutlaşdırmaya və ya aşağı axın xidmətinə işarə edir. Cavab verməyi dayandıran həmkar əlçatanlığa və ya uzaq tərəfin öz vəziyyətinə işarə edir.

Təhlükəsizlik assosiasiyalarını brauzerdən əvvəl oxuyun

Demon soruşduqdan sonra idarəetmə vəziyyəti və məlumat vəziyyəti ayrıca sadalanır və sayğaclar ümumiyyətlə nəyinsə cəhd edilib-edilmədiyini bildirir. Heç quraşdırılmamış uşaq assosiasiyası quraşdırılıb sonra paket keçirməyi dayandıran assosiasiyaya heç bənzəmir, halbuki hər ikisi eyni istifadəçi şikayətini yaradır.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Vəziyyət adlarını biletdə hərfi-hərfinə yazın, şikayət anındakı sayğaclarla birlikdə. Tunel söndü kimi təsvir iki assosiasiyadan hansının bitdiyini gizlədir və bu adətən saxlanmağa dəyər yeganə faktdır.

Marşrut nasazlığı ölü həmkara tam bənzəyir

Şlüz idarəetmə mübadilələrinə cavab verə bilər, halbuki şəxsi server oflayndır, yönləndirilən marşrut yoxdur və ya daxili ad həlli tamamilə uğursuz olur. Müştəri tərəfdən bunların hamısı işləyən sessiya və işləməyən təyinat kimi görünür. Qayıdış yolunu da irəli yol qədər diqqətlə yoxlayın, çünki uzaq tərəfdə asimmetrik marşrutlaşdırma yalnız bir istiqamətdə səssizlik yaradır.

Tunelin işləyib-işləmədiyini yoxlamaq əvəzinə, nəzərdə tutulan tətbiqi birbaşa sınayın və onun cəhd etdiyi ünvanı adlandırın. Şlüzə ping şlüzün cavab verdiyini sübut edir; tətbiqin cavab verdiyini heç vaxt sübut etməmişdir. Tətbiqin cəhd etdiyi dəqiq ünvanı qeyd edin. Bu sətir sonradan axtarışı daraldır və biletdə adətən buraxılan yeganə faktdır.

Taymerləri diaqnozdan kənarda saxlayın

Aşkarlama intervalını qısaltmaq performans dəyişikliyi deyil və tutum əlavə etmir. Paket itkisi şəraitində bu, nasazlığın nə qədər tez tanındığını dəyişir, bu da heç nəyi yaxşılaşdırmadan simptomu fərqli göstərə bilər. Əvvəlcə nasazlığın real vaxtını qeyd edin, sonra toleransın həqiqətən sahib olduğunuz keçid üçün səhv olub-olmadığına qərar verin.

NAT xəritələmə yeniləmələri də eyni kateqoriyaya aiddir. Onlar tərcümə edilmiş yolu işlək saxlayır və uzaq tətbiqin işlədiyinə dair sübut deyillər.

Tam bərpa siyasəti həmkar ölü elan edildikdə müştərinin nə etməli olduğunu deyir: yenidən başlatmaq, bağlamaq və ya gözlətmək, və bu baş verərkən digər trafikin nə edə biləcəyini. Bu olmadan eyni hadisə hər rübdə sıfırdan yenidən diaqnoz edilir.