IKEv2 tək bir əl sıxışması deyil: əvvəl IKE SA, sonra autentifikasiya, sonra CHILD SA
Şlüz cavabı çatıla bilənliyi sübut edir, şəxsiyyəti yox. IKE_SA_INIT, IKE_AUTH və ilk CHILD SA-nı izləyin, sonra trafik axmadan əvvəl nəyin doğru olmalı olduğunu yoxlayın.
IKEv2 bağlantısının trafikinizin şifrələnməsi ilə bitən tək bir mübadilə olduğunu düşünə bilərsiniz. Əslində ən azı ikidir və birincisi heç kimi autentifikasiya etmir. Tərəflər nəzarət mesajları ilə başlayır, kriptoqrafik parametrlər üzərində razılaşır, şəxsiyyəti sübut edir və yalnız bundan sonra tətbiq paketlərini daşıyan vəziyyəti razılaşdırır. Bu sıra insanların daim bildirdiyi uyğunsuzluğu izah edir: şlüz cavab verir, müştəri qoşulduğunu deyir, amma şəxsi tətbiq yenə də vaxt aşımına düşür. Budur hər mərhələnin həqiqətən nə etdiyi və ondan sonra nəyin doğru olmalı olduğu.
Mif: şlüz cavab verirsə, siz qoşulmusunuz
İlk mesaja cavab son nöqtənin çatıla bilən və danışmağa hazır olduğunu sübut edir. Hesabın qəbul edildiyini, sertifikat zəncirinin doğrulandığını və ya hər hansı məlumat siyasətinin quraşdırıldığını sübut etmir.
Bu uğursuzluqlar sonra baş verir və fərqli simptomlar yaradır. Sertifikat rəddi və ya EAP uğursuzluğu ilk mübadilə artıq uğurlu olduqdan sonra gəlir, buna görə də UDP 500-ə ping və yaşıl müştəri ikonu bu qədər az şey deyir.
IKE_SA_INIT: parametrlər üzərində razılaşma, şəxsiyyət yox
İlk mübadilə IKE təhlükəsizlik assosiasiyası üçün təkliflər daşıyır: şifrələmə və bütövlük alqoritmləri, psevdotəsadüfi funksiya və Diffie-Hellman qrupu. Tərəflər həmçinin nonce mübadiləsi edir və hər tərəf bu dəyərlərin yaratdığı ümumi sirdən IKE SA üçün açar materialı çıxarır. Bu mübadilədə heç nə qarşı tərəfin kim olduğunu müəyyən etmir. O, yalnız hər iki tərəfin eyni açarları hesablaya bildiyini və bir təklif üzərində razılaşdığını təsdiqləyir. Heç bir təklifi bəyənməyən cavab verən burada mübadiləni rədd edir, buna görə versiya və ya alqoritm uyğunsuzluğu serverin işləmədiyi kimi görünür.
Bu mərhələdə yaradılan IKE SA bütün sonrakı idarəetmə mübadilələrini qoruyur. Onun vəzifəsi budur və bu, paketlərinizi qorumaq vəzifəsindən fərqlidir.
IKE_AUTH: şəxsiyyəti sübut et, sonra ilk CHILD SA-nı qur
İkinci mübadilə şəxsiyyəti daşıyır. Sertifikatlarla hər tərəf öz şəxsi açarı ilə imzalayır və digər tərəfin doğrulamalı olduğu zənciri təqdim edir; EAP ilə cavab verən başladanı seçilmiş üsulla sınağa çəkir. Səhv server adı, vaxtı keçmiş sertifikat və ya rədd edilmiş parol burada nəhayət üzə çıxır.
Normal halda IKE_AUTH ilk CHILD SA-nı da razılaşdırır, buna görə məlumat mühafizəsi eyni gedişdə razılaşdırılır. Başladan trafik seçicilərini təklif edir, cavab verən onları daraldır və ya rədd edir, məlumat yolu üçün açarlar IKE SA-dan çıxarılır. Bu o deməkdir ki, tək bir mübadilə iki çox fərqli yerdə uğursuz ola bilər: şəxsiyyət və ya siyasət. Ümumi handshake xətası yerinə notify yükünü və ya xətanı oxuyun, çünki birinin düzəlişi sertifikat, digərinin düzəlişi isə subnet uyğunsuzluğudur.
İki SA, iki vəzifə
| Association | Protects | Lifetime behaviour |
|---|---|---|
| IKE SA | Management exchanges: rekeying, delete, configuration payloads | Rekeyed on its own schedule; the data path can survive the change |
| CHILD SA | Application traffic matching the traffic selectors | Rekeyed independently, often more frequently |
Onları ayrı saxlamaq səhv kimi görünən iki davranışı izah edir. Tunel qurulmuş görünə bilər, halbuki arxa planda yenidən açar yaradılması uğursuz olur, və CHILD SA müştərinin bağlantını itirməsi olmadan dəyişdirilə bilər.
strongSwan-da IKEv2 konfiqurasiya sənədi və swanctl --list-sas hər iki səviyyəni göstərir, ip xfrm state ilə ip xfrm policy isə nüvənin həqiqətən quraşdırdığını göstərir. Bu iki görünüşü müqayisə etmək razılaşmanın bitdiyini və ya yalnız bitmiş göründüyünü görməyin ən sürətli yoludur. Demon CHILD SA siyahıya alırsa, lakin nüvədə onun üçün vəziyyət yoxdursa, quraşdırma səssizcə uğursuz olub. Nüvə demonun bilmədiyi vəziyyəti saxlayırsa, əvvəlki cəhdin qalığına baxırsınız.
Tunel qurulduqdan sonra hələ nə doğru olmalıdır
Trafik seçiciləri hansı ünvanların əhatə olunduğunu müəyyən edir. Müştəri bir subnet təklif edir, server başqasını gözləyirsə, CHILD SA quraşdırılır, amma faydalı heç nə daşımır, və xəta danışıq problemi kimi deyil, marşrutlaşdırma problemi kimi görünür. Sonra yerli stek əməkdaşlıq etməlidir: hostun marşrutlaşdırdığı yerdə yönləndirmə aktiv olmalı, marşrutlar tunelə yönəlməli, firewall qaydaları deşifrə edilmiş paketlərə icazə verməli və şəxsi adlar iştirak edirsə daxili həlledici olmalıdır. Bunların hər biri ayrıca uğursuz olur və heç biri IKE demonunu yenidən başlatmaqla düzəlmir.
Diaqnoz qoyarkən jurnalı görünən saxlayın: ilkin mübadilə, sonra şəxsiyyətin yoxlanması, sonra tətbiq olunan yerdə istifadəçi autentifikasiyası, sonra CHILD quraşdırılması, sonra tətbiq trafiki. Dayanan mərhələ düzəldilməli mərhələdir və sonrakı marşrutlaşdırma uğursuzluğu heç vaxt artıq keçmiş şəxsiyyət yoxlamalarını yumşaltmaq üçün səbəb deyil.