IPsec IPsec içində: xarici tunel hansı ünvanları daşımalıdır
Xarici tunelə daxili şlüz ünvanlarını verin, tətbiq alt şəbəkələrini deyil. Sonra hər qatda yönləndirməni, tərcüməni və MTU-nu sübut edin ki, ona iç-içə deyə biləsiniz.
İç-içə IPsec haqqında düşünmək iki qat müxtəlif maşınlarda tamamlandıqda daha asandır. Dörd şlüz, iki tunel və dizaynın işləyib-işləmədiyini həll edən bir sual: daxili tunel paketlə işini bitirdikdən sonra xarici tunel əslində nə görür? Buna cavab verin, selektorlar, marşrutlar və nasazlıqların aradan qaldırılması sırası ondan sonra gəlir. Səhv edin və texniki olaraq işləyən tuneli bir gün boyu sazlayacaqsınız.
Dörd şlüzlü model
Xarici A və B şlüzləri iki sayt arasında ilk tuneli qurur. A-nın arxasında tranzit ünvanı 10.60.0.2 olan daxili C şlüzü dayanır; B-nin arxasında isə tranzit ünvanı 10.70.0.2 olan daxili D şlüzü dayanır. Tətbiq şəbəkələri C və D-nin arxasındadır və nümunədəki hər ünvan qəsdən üst-üstə düşmür.
application net -> C -> A == outer IPsec == B -> D -> application net
\---------- inner IPsec ----------/
C transit: 10.60.0.2 D transit: 10.70.0.2
A and B: underlay addresses only
Qatları dörd host arasında bölmək hər maşının bir sərhəd tətbiq etməsi deməkdir. Hər iki qatı bir hostda işlədən zaman iki siyasət dəsti, iki marşrut cədvəli və iki nasazlıq rejimini bir maşında uzlaşdırmaq lazımdır; bu mümkündür və müşahidə etmək xeyli çətindir.
Hər qat yalnız öz müdafiəsini götürür
C, D üçün tətbiq paketini şifrələyir. Nəticə C-dən D-yə ünvanlanır və A-ya çatan da məhz budur. Aşağıdakı hər şey bu yenidən yazılmadan asılıdır.
A onu B üçün yenidən şifrələyir. B xarici qatı deşifrə edir, C-dən D-yə gedən paketi görür və onu hələ də şifrəli olaraq yönləndirir. D daxili müdafiəni götürür və tətbiq paketini çatdırır.
Beləliklə, A və B daxili son nöqtələri və onların metadatasını görür, lakin tətbiq yükünü deşifrə edən tərəflər deyillər. Bu, dizaynın real xüsusiyyətidir və C, D və ya tətbiq hostlarının etibarlı olduğu iddiası deyil.
Xarici selektorlar daxili şlüzləri adlandırır
Bu qurğuların çoxu məhz burada uğursuz olur. Siyasət əsaslı xarici tunel üçün razılaşdırdığınız selektorlar A və B-nin həqiqətən idarə etdiyi ünvanları ehtiva etməlidir: 10.60.0.2/32 və 10.70.0.2/32, düzgün yerli və uzaq sıra ilə.
Son tətbiq alt şəbəkələrini xarici selektorlara qoymaq işləmir, çünki paket A-ya çatanda daxili inkapsulyasiya A-nın qorumalı olduğu şeyi artıq yenidən yazıb. Onda xarici siyasət heç nəyə uyğun gəlməyəcək və tunel heç bir data daşımadan qalxacaq.
Xarici icazəni UDP 500-ə də daraltmayın. Daxili bağlantının öz data yolu var; razılaşdırdığından asılı olaraq ESP və ya UDP inkapsulyasiyası istifadə edir və xarici siyasət həmin protokola icazə verməlidir.
Nəticəni hər şlüzdə swanctl --list-sas ilə yoxlayın və uşaq təhlükəsizlik assosiasiyalarının nəzərdə tutduğunuz ünvanları bildirdiyini, güman etdiyinizi deyil, təsdiqləyin. Əgər siyahı tətbiq alt şəbəkələrini göstərirsə, xarici siyasət səhv qat üçün yazılıb. Marşrutlaşdırmanı sazlamadan əvvəl selektorları düzəldin, çünki marşrutlar yaxşı görünəcək, sayğaclar isə tərpənməyəcək.
Yönləndirmə və rekursiya tələsi
Selektorlar marşrutları əvəz etmir. A və B C ilə D arasında trafiki hər iki istiqamətdə yönləndirməlidir, yəni IP yönləndirmə aktiv olmalı, marşrutlar tunelə baxmalı və qarşı tərəfdə qayıdış yolu mövcud olmalıdır.
Xarici tunel XFRM interfeyslərindən istifadə edirsə, marşrutlar interfeysi seçir, razılaşdırılmış siyasətlər isə onun daşıdığını hələ də məhdudlaşdırır. İnterfeys qorunanı genişləndirmir; yalnız nüvənin paketi necə götürməsini dəyişir.
Tələ rekursiyadır. A-nın B-nin xarici son nöqtəsinə marşrutu əsas şəbəkəyə uymalıdır, A-nın qurduğu tunelə deyil; əks halda inkapsulyasiya öz içində səyahət etməyə çalışır və bağlantı heç vaxt tamamlanmır.
Qatlar əlavə etməzdən əvvəl tərcüməni yoxlayın
Başqa heç nəyi tənzimləməzdən əvvəl A və B-dəki hər hansı mənbə NAT-a baxın. IPsec siyasəti tətbiq olunmadan əvvəl C-nin ünvanını yenidən yazan qayda razılaşdırılmış selektorları poza bilər və D-nin qarşı tərəfdə nə aldığını da dəyişə bilər.
Geniş maskarad iki qatın olması ilə daha təhlükəsiz olmur. Uzaq tərəfin hansı ünvanı gördüyünü gizlədir, halbuki tunel işləyib tətbiq işləmədikdə məhz bu məlumata ehtiyacınız olur.
Əgər NAT qaydası həqiqətən lazımdırsa, hər tərəfin hansı ünvanla danışdığını düşündüyünü yazın. Bu bir sətir tunelin, yoxsa tərcümənin günahkar olduğu barədə mübahisələrin çoxunu həll edir. Bir il sonra qayda silinəndə növbəti mühəndisə hara baxacağını da deyir. Ping bunların heç birini etməyəcək.
Fail-closed-u sübut edin və MTU-nu yoxlayın
Marşrutun yox olması tək başına fail-closed siyasəti deyil. Başqa cədvəl, defolt marşrut və ya siyasət qaydası səssizcə ehtiyat yol verə bilər və bunu bilməyin yeganə yolu xarici tuneli söndürüb tətbiq trafikinin nə etdiyini müşahidə etməkdir. Bunu təsadüfən kəşf etmək əvəzinə qəsdən, pəncərə daxilində edin.
Üç vəziyyəti sınaqdan keçirin: xarici tunel söndürülmüş, daxili tunel söndürülmüş və hər ikisi qayıtdıqdan sonra bərpa. Hər şlüzdə siyasət sayğaclarından istifadə edin, çünki qurulmuş iki IKE sessiyası yalnız idarəetmə müstəvisi danışıqlarının uğurla keçdiyini sübut edir.
Hər iki inkapsulyasiya üçün büdcə ayırın. İşləyən IKE kiçik paket nəticəsidir və tam ölçülü tətbiq paketləri iki başlıq əlavə olunduqdan sonra hələ də uğursuz ola bilər; rəqəmlərin toplandığını güman etmək əvəzinə real yolda məlum yük ölçüsü ilə sınaqdan keçirin. Arifmetika asandır, yol deyil.