IPsec ichida IPsec: tashqi tunnel qaysi manzillarni olib yurishi kerak

Ichma-ich IPsec haqida fikr yuritish ikki qatlam turli mashinalarda tugaganda osonroq. To'rt shlyuz, ikkita tunnel va dizayn ishlaydimi-yo'qmi degan bitta savol: ichki tunnel paket bilan ishini tugatgandan so'ng tashqi tunnel aslida nimani ko'radi? Bunga javob bering, selektorlar, marshrutlar va muammolarni hal qilish tartibi o'z-o'zidan keladi. Xato qilsangiz, texnik jihatdan ishlab turgan tunnelni debug qilishga bir kun sarflaysiz.

To'rt shlyuzli model

Tashqi shlyuzlar A va B ikki sayt o'rtasidagi birinchi tunnelni quradi. A orqasida tranzit manzili 10.60.0.2 bo'lgan ichki shlyuz C, B orqasida tranzit manzili 10.70.0.2 bo'lgan ichki shlyuz D turadi. Ilova tarmoqlari C va D orqasida yashaydi va misoldagi har bir manzil ataylab ustma-ust tushmaydi.

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

Qatlamlarni to'rt hostga bo'lish har bir mashina bitta chegarani bajarishini bildiradi. Ikki qatlamni bitta hostda ishga tushirganda bitta mashinada ikki siyosat to'plami, ikki marshrut jadvali va ikki nosozlik rejimini uyg'unlashtirish kerak, bu mumkin va kuzatish ancha qiyin.

Har bir qatlam faqat o'z himoyasini olib tashlaydi

C D uchun ilova paketini shifrlaydi. Natija C dan D ga manzillanadi va A ga yetib boradigan ham shu. Keyingi hamma narsa shu qayta yozishga bog'liq.

A uni B uchun yana shifrlaydi. B tashqi qatlamni ochadi, C dan D ga ketayotgan paketni ko'radi va uni hali ham shifrlangan holda uzatadi. D ichki himoyani olib tashlab, ilova paketini yetkazadi.

Shunday qilib, A va B ichki oxirgi nuqtalarni va ularning metama'lumotlarini ko'radi, lekin ilova yukini ochadigan tomonlar ular emas. Bu dizaynning haqiqiy xususiyati, C, D yoki ilova hostlari ishonchli degan da'vo emas.

Tashqi selektorlar ichki shlyuzlarni nomlaydi

Aynan shu yerda bunday qurilmalarning ko'pchiligi muvaffaqiyatsiz bo'ladi. Siyosatga asoslangan tashqi tunnel uchun siz kelishadigan selektorlar A va B haqiqatan ishlaydigan manzillarni o'z ichiga olishi kerak: 10.60.0.2/32 va 10.70.0.2/32, to'g'ri mahalliy va uzoq tartibda.

Yakuniy ilova subnetlarini tashqi selektorlarga qo'yish ishlamaydi, chunki paket A ga yetganda ichki inkapsulyatsiya A himoya qilishi kerak bo'lgan narsani allaqachon qayta yozgan bo'ladi. Shunda tashqi siyosat hech narsaga mos kelmaydi va tunnel ma'lumot olib yurmasdan ko'tariladi.

Tashqi ruxsatni UDP 500 ga toraytirmang. Ichki ulanishning o'z ma'lumot yo'li bor, u kelishilganiga qarab ESP yoki UDP inkapsulyatsiyasidan foydalanadi va tashqi siyosat bu protokolga ruxsat berishi kerak.

Har bir shlyuzda swanctl --list-sas yordamida natijani tekshirib, bolalar xavfsizlik assotsiatsiyalari siz nazarda tutgan manzillarni xabar qilishiga, siz taxmin qilganlarini emas, ishonch hosil qiling. Agar ro'yxat ilova subnetlarini ko'rsatsa, tashqi siyosat noto'g'ri qatlam uchun yozilgan. Marshrutlashni debug qilishdan oldin selektorlarni tuzating, chunki marshrutlash yaxshi ko'rinadi, hisoblagichlar esa qimirlamaydi.

Uzatish va rekursiya tuzog'i

Selektorlar marshrutlash o'rnini bosmaydi. A va B C bilan D o'rtasida trafikni ikki yo'nalishda ham uzatishi kerak, ya'ni IP uzatish yoqilgan, tunnelga ishora qiluvchi marshrutlar va qarshi tomonda mavjud qaytish yo'li.

Agar tashqi tunnel XFRM interfeyslaridan foydalansa, marshrutlar interfeysni tanlaydi, kelishilgan siyosatlar esa u nima olib yurishini hali ham cheklaydi. Interfeys himoyalangan hududni kengaytirmaydi; u faqat yadro paketni qanday olishini o'zgartiradi.

Tuzoq — rekursiya. A ning B tashqi oxirgi nuqtasiga marshruti A qurayotgan tunnelga emas, pastki tarmoqqa ergashishi kerak, aks holda inkapsulyatsiya o'z ichida sayohat qilishga urinadi va ulanish hech qachon tugamaydi.

Qatlamlar qo'shishdan oldin tarjimani ko'rib chiqing

Boshqa narsani sozlashdan oldin A va B dagi har qanday manba NAT ni ko'ring. IPsec siyosati qo'llanilishidan oldin C manzilini qayta yozadigan qoida kelishilgan selektorlarni buzishi mumkin, shuningdek D qarshi tomonda nima olishini ham o'zgartirishi mumkin.

Keng maskirovka ikki qatlam bo'lgani uchun xavfsizroq bo'lmaydi. U uzoq tomon qaysi manzilni ko'rishini yashiradi va tunnel ishlab, ilova ishlamayotganda aynan shu ma'lumot kerak bo'ladi.

Agar NAT qoidasi haqiqatan zarur bo'lsa, har bir tomon qaysi manzil bilan gaplashyapti deb o'ylashini yozib qo'ying. Shu bitta satr tunnelmi yoki tarjimami aybdor degan bahslarning ko'pini hal qiladi. Shuningdek, bir yildan keyin qoida olib tashlanganda keyingi muhandisga qayerga qarashni aytadi. Ping bularning hech birini qilmaydi.

fail-closed ni isbotlang va MTU ni tekshiring

Marshrutning yo'qolishi o'z-o'zidan fail-closed siyosati emas. Boshqa jadval, standart marshrut yoki siyosat qoidasi jimgina zaxira yo'l berishi mumkin va buni bilishning yagona yo'li tashqi tunnelni tushirib, ilova trafigi nima qilishini kuzatishdir. Buni tasodifan aniqlash o'rniga texnik xizmat oynasida ataylab qiling.

Uch holatni sinab ko'ring: tashqi tunnel pastda, ichki tunnel pastda va ikkalasi qaytgandan keyin tiklanish. Har bir shlyuzda siyosat hisoblagichlaridan foydalaning, chunki o'rnatilgan ikki IKE sessiyasi faqat boshqaruv tekisligidagi muzokaralar muvaffaqiyatli bo'lganini isbotlaydi.

Ikkala inkapsulyatsiya uchun byudjet ajrating. Ishlaydigan IKE kichik paketlarning natijasi va ikki sarlavha qo'shilgandan keyin to'liq o'lchamdagi ilova paketlari hali ham muvaffaqiyatsiz bo'lishi mumkin; raqamlar qo'shiladi deb taxmin qilish o'rniga haqiqiy yo'lda ma'lum yuk hajmi bilan sinab ko'ring. Arifmetika oson, yo'l esa unday emas.