strongSwan ESP-in-UDP: aşkar ediləsi NAT olmadıqda

NAT aşkarlanması ünvan çevrilməsini tapır, firewall siyasətini yox. NAT-ı olmayan sayt bağlantısı yenə də açıq ESP-in-UDP seçiminə ehtiyac duya bilər.

NAT aşkarlanması bir suala cavab verir: ünvanlar və ya portlar yolda dəyişibmi? O, firewall-un IP protokolu 50-yə icazə verib-vermədiyinə cavab vermir. Heç bir çevrilməsi olmayan sayt şlüzləri yenə də native ESP-ni atan siyasətin arxasında qala bilər və bu tələb aşkarlanmaqla deyil, konfiqurasiya edilməklə həll olunur. Mexanizm ESP-in-UDP-dir və bu, öz-özünə yaranan ehtiyat variant deyil, qərardır.

Aşkarlanma ünvanlar üzərində arifmetikadır, firewall yoxlaması deyil

IKEv2 NAT aşkarlama yüklərini mənbə və təyinat ünvanlarının və portlarının heşlərini daşıyır. Hər tərəf aldığını yerli olaraq gördüyü ilə müqayisə edir və uyğunsuzluq ona paketi nəyinsə çevirdiyini bildirir. Bu mübadilədə heç nə ortadakı marşrutlaşdırıcının 50 protokolunu ötürüb-ötürmədiyini yoxlamır.

Praktik nəticəni açıq deməyə dəyər. Native ESP ilə işləyən tunel yeni məhdudlaşdırıcı firewall-u özü aşkar etməyəcək və növbəti cəhdi IKE uğurlu qalarkən məlumat mərhələsində uğursuz olacaq. Siz qurulmuş IKE təhlükəsizlik assosiasiyaları görəcəksiniz və qorunan trafik olmayacaq, bu da simdə tutana qədər marşrutlaşdırma xətası kimi görünür.

Buna görə inkapsulyasiya konfiqurasiya etdiyiniz bağlantının xassəsidir, həmyaşıdların şəbəkənin davranışından danışıb əldə etdiyi nəticə deyil.

Encap mübadiləni necə dəyişir

Müasir strongSwan quraşdırmasında swanctl.conf faylı ilə idarə olunan bağlantıda encap = yes təyini NAT aşkarlama mübadiləsinə təsir edir ki, hər iki həmyaşıd ESP üçün UDP inkapsulyasiyasından istifadə etsin. Sonra qorunan paketlər UDP içində, adətən 4500 portunda hərəkət edir və hər iki son nöqtə bu düzülüşdə razılaşmalıdır.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Bu fraqment real bağlantı tərifinin içinə aiddir və tam sayt profili deyil. Artıq işlətdiyiniz həmyaşıd ünvanlarını, autentifikasiyanı və child trafik seçicilərini saxlayın; əlavə olunan tək açar qorunan məlumatın necə büküldüyünü dəyişir, onun nəyi qoruduğunu yox.

strongSwan-ın NAT-traversal bələdçisi bu davranışı, o cümlədən MOBIKE istifadə edildikdə port sürüşməsi ilə qarşılıqlı təsiri təsvir edir.

Öz backend-inizə aid təyimi istifadə edin

strongSwan-ın iki konfiqurasiya backend-i var və açar onlar arasında fərqlidir. swanctl.conf bağlantısı encap qəbul edir, köhnə ipsec.conf bağlantısı isə forceencaps qəbul edir. Bir backend-in açar sözünü digərinə atmaq şikayətsiz yüklənən və heç nəyi dəyişməyən konfiqurasiya yaradır ki, bu da xətadan pisdir.

Hər şeyi redaktə etməzdən əvvəl hansı demonun həqiqətən işlədiyini yoxlayın. Bir çox distributivdə hər iki fayl mövcuddur, çünki biri əvvəlki miqrasiyadan qalıbdır və aktiv olan xidmət vahidinin başlatdığıdır. Fayl vaxt möhürlərindən təxmin etmək əvəzinə həmin vahidi oxuyun. Buradakı beş saniyəlik yoxlama heç nəyin yükləmədiyi təyimin saatlarla sınaqdan keçirilməsinin qarşısını alır.

Dəyişikliyi bağlantı sahibi vasitəsilə tətbiq edin və assosiasiyanı nəzarət edilən pəncərədə yenidən qurun. Artıq quraşdırılmış child dəyişdirilənə qədər cari inkapsulyasiyasını saxlayır, ona görə yalnız fayl redaktəsi yeni düzülüşün istifadədə olduğunu sübut etmir.

Bükülmüş məlumatı yoxlayın, təkcə portu yox

Qorunan trafik axarkən şlüzdə tutun, sonra bunu strongSwan-ın öz görünüşü ilə müqayisə edin:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP IP protokolu 50 kimi görünür və UDP-yə heç bənzəmir. Bükülmüş ESP 4500 üzərində UDP dataqramları kimi görünür və onların yükü IKE deyil. Həmin portdakı IKE trafiki inkapsulyasiyanın sübutu deyil, çünki MOBIKE IKE-ni ora köçürə bilər, məlumat yolu isə native qalır, ona görə port nömrəsini deyil, yükü oxuyun.

Path MTU-nu da yadda saxlayın. Qablaşdırma əlavə yük gətirir və native ESP daşımış yol paketlər böyüdükcə düzəlişlərə ehtiyac duya bilər. Tələb olunan ICMP idarəetməsi artıq dizaynın bir hissəsi olmalıdır; inkapsulyasiya bu asılılığı aradan qaldırmır.

Dəyişikliyi o zaman qəbul edin ki, tuneldəki təzə tətbiq trafiki hər iki uçda tutmada bükülmüş ESP kimi görünür və daxili xidmət və onun qayıdış marşrutu hələ də işləyir. Bundan azı faylda düzgün görünən konfiqurasiyadır.

Əlaqəli məqalələr