Təyin edilmiş virtual IP ünvanında IKEv2 müştərisinə çatmaq

Şlüz IKEv2 üzərindən ona qoşulmuş noutbuka bağlantı başlatmalıdır və bunun üçün həmin müştərinin təyin edilmiş virtual ünvanından istifadə etməlidir. Tunel açıqdır, müştəri şlüzün arxasındakı hər şeyə çatır, əks istiqamət isə yenə də uğursuz olur. Bu asimmetriya normaldır: razılaşdırılmış siyasət hansı ünvanların danışa biləcəyini təsvir edir, hansı tərəfin başlaya biləcəyini yox. Şlüzdən başlayan sorğunun işləməsi üçün üç şey üst-üstə düşməlidir.

Tunel mənbə ünvanını düzəltmir

CHILD SA hər tərəf üçün bir olmaqla bir cüt trafik seçicisini əhatə edir və həmin cütün hər iki istiqamətində trafikə icazə verir. O, IKE mübadiləsini ilk hansı tərəfin açdığı barədə heç nə demir. Əvvəlcə tuneli dinləyən şlüz ilk tətbiq paketini yenə də göndərə bilər, bu şərtlə ki, seçilmiş mənbə və təyinat quraşdırılmış seçicilərin içində olsun. Sorğu yanlış interfeysdən çıxdıqda, o, sadəcə olaraq tunel üçün uyğun deyil.

Müştəriyə doğru marşrutlaşdırma zəruridir və kifayət deyil. Siyasət faktiki istifadə etdiyiniz mənbəni qəbul etməlidir.

Quraşdırılmış siyasəti oxuyun, konfiqurasiya faylını yox

Aktiv assosiasiyadan və onun seçicilərindən başlayın, çünki dinamik təyinat nüvədə quraşdırılanı dəyişir.

ipsec statusall
ip xfrm policy

Status çıxışı bağlantının adını, təyin edilmiş virtual ünvanı və həmin tərəf üçün hazırda qüvvədə olan seçiciləri göstərir. Siyasət boşaltması eyni seçiciləri nüvə vəziyyəti kimi göstərir və paket seçimi faktiki olaraq məhz ona müraciət edir. Şlüz tərəfindəki seçicini tətbiqinizin istifadə edəcəyi mənbə ilə müqayisə edin, çünki uyğunsuzluq nasazlığı dərhal izah edir. Müştərinin cari ünvanını oxuyun, əvvəlki sessiyadan olan ünvanı yox, çünki yenidən təyin edilmiş VIP köhnə siyasəti etibarsız edir.

Müştəri paketin gəldiyi yerdə dinləməlidir

Hətta mükəmməl siyasət də xidmət yalnız loopback-ə bağlandıqda bağlı porta çatır. Dinləyici təyin edilmiş ünvanda və ya yerli wildcard ünvanda olmalıdır.

ss -ltnp 'sport = :9090'
iptables -S INPUT

Soket siyahısı portun virtual ünvana bağlı olub-olmadığını, firewall qaydaları isə qorunan mənbədən yeni bağlantıların qəbul edilib-edilmədiyini göstərir. Qurulmuş bağlantılar üçün yazılmış qayda şlüzün başlatdığı bağlantını qəbul etmir. Xidmətin öz autentifikasiyasını saxlayın, çünki tuneldən gəlmək yalnız paketin hansı şəbəkədən gəldiyini müəyyən edir. Öz NAT-ının arxasındakı müştəri yenə də gələn port yönləndirməsinə ehtiyac duymur, çünki bu sorğular mövcud tunelin içində hərəkət edir.

Yeni istiqaməti təkbaşına sınaqdan keçirin

İşləyən müştəridən serverə sorğu bu yolu heç vaxt sınaqdan keçirmir. Sorğunu şlüzdən yaradın və hər iki tərəfi müşahidə edin.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Marşrut axtarışı şlüzün hansı mənbə və interfeysdən istifadə edəcəyini cavablandırır və siyasətin qəbul etməli olduğu dəyər budur. Tutma sorğunun ictimai interfeysdə adi TCP kimi deyil, ESP içində çıxdığını göstərməlidir. Müştəridə, çatmağı və xidmətin cavab verib-vermədiyini təsdiqləmək üçün şifrəsi açılmış trafiki tutun. Əgər sorğu naqildə ESP olmadan yox olursa, müştərinin firewall-undan əvvəl mənbə ünvanından şübhələnin.

Açarın yenilənməsindən və ya yenidən qoşulmadan sonra testi təkrarlayın, çünki VIP dəyişə bilər. Yalnız növbəti sessiyaya qədər işləyən yol işlək yol deyil.