strongSwan'da to'liq tunnel ikkala tomonda ham 0.0.0.0/0 talab qiladi

To'liq tunnel mijozning remote_ts va shlyuzning local_ts sifatida 0.0.0.0/0, shuningdek yo'naltirish, NAT va qaytish marshrutini talab qiladi. To'rttasini ham tekshiring.

Bitta xususiy tarmoqcha uchun ishlaydigan strongSwan ulanishi kimdir bitta qatorni tahrirlagani uchun internet trafigini tashimaydi. To'liq tunnel — bu child SA qaysi manzillarni himoya qilishi haqida ikki tomonning kelishuvi va har bir tomon ikkinchisini o'ziga nisbatan nomlaydi. Bir tomonni to'g'ri, ikkinchisini noto'g'ri qilsangiz, child SA yo ko'tarilmaydi yoki mo'ljallangandan tor ko'tariladi. Quyidagi beshta tekshiruv bu kelishuvni mijozdan shlyuz orqali internetgacha kuzatib boradi.

Avval mijozning selektorini tekshiring

Mijoz uzoq tomonda nimani himoya qilmoqchi ekanini remote_ts sifatida tavsiflaydi va yuborgan hamma narsasi o'ziga berilgan manzildan chiqadi. Internet trafigi uchun bu qiymat foydalanuvchi haqiqatda yetib boradigan manzillarni qamrab olishi kerak, bu amalda butun IPv4 fazosini bildiradi. Hali ham bitta tarmoqchani sanab o'tayotgan mijoz interfeysdagi profil nomi qanday bo'lishidan qat'i nazar bo'lingan tunnel so'raydi. Manba tomoni odatda dynamic, chunki manzil ulanish paytida beriladi. U yerga yozilgan qat'iy manba manzillar to'plami o'zgarishi bilanoq buziladi.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Bu parcha to'liq ulanish fayli emas va u autentifikatsiya, identifikatsiyalar hamda virtual manzillar to'plami allaqachon sozlangan deb hisoblaydi. Mijozning manba selektori va server beradigan manzil hali ham mos kelishi kerak, aks holda child SA hech bir tomon kutmagan qamrov bilan ko'tariladi. Uni swanctl --load-all bilan yuklang va muvaffaqiyat deb hisoblashdan oldin chiqishni o'qing. Tahlil qilinadigan fayl ham boshqa tomon taklifiga to'g'ri kelmaydigan selektor sababli rad etilishi mumkin.

Shlyuzning selektorini o'z tomonida tekshiring

Shlyuz xuddi shu tushunchani qarama-qarshi yo'nalishdan o'qiydi. Internet manzillari shlyuz uchun mahalliy, shuning uchun uning local_ts keng va remote_ts mijozlar to'plamini tavsiflaydi. Bu teskari aylanish to'liq tunnel sozlamasidagi eng ko'p uchraydigan xato va u ko'rikdan o'tadi, chunki ikkala qator alohida ishonchli ko'rinadi.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Mijoz parchasini shlyuz fayliga ko'chirish foydali hech narsani tavsiflamaydigan selektor juftini yaratadi, chunki ikkala tomon ham bir xil rolni talab qiladi. strongSwan yo'naltirish qo'llanmasi mijoz va shlyuz juftlashuvini aniq hujjatlashtiradi va uni muvaffaqiyatsizlikdan keyin emas, ulanish fayli yonida o'qish arziydi. Shlyuz fayliga remote_ts havola qiladigan to'plam ta'rifi ham kerak. Mavjud bo'lmagan to'plamni nomlaydigan selektor shikoyatsiz yuklanadi va ulanishda muvaffaqiyatsiz bo'ladi.

Eski ipsec.conf turli kalitlar bilan chap va o'ng rollarni ishlatadi, rightsubnet qatori esa swanctl qiymatining to'g'ridan-to'g'ri o'rnini bosmaydi. Ikki sintaksisni birini ikkinchisiga yopishtirish o'rniga alohida fayllarda saqlang. Ularni bitta katalogda aralashtirish ishlaydigan ulanishning qayta yuklashdan keyin jimgina orqaga qaytish yo'lidir.

Faylni emas, kelishilgan child SA ni tekshiring

Saqlangan konfiguratsiya niyatni isbotlaydi va boshqa hech narsani emas. Boshqa tomon so'ralganini toraytirishi mumkin va mavjud child SA uning ostidagi fayl o'zgargani uchungina almashtirilmaydi. Boshqa narsani o'zgartirishdan oldin aslida nima o'rnatilganini tasdiqlang.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Birinchi buyruq demon nima yuklaganini, ikkinchisi o'rnatilgan child SA larni, uchinchisi yadro qo'llaydigan siyosatlarni ko'rsatadi. Agar fayl 0.0.0.0/0 desa va ro'yxat bitta tarmoqchani ko'rsatsa, muzokaralar qamrovni toraytirgan va faylni qayta o'qish buni tushuntirmaydi. child ni to'xtating, qayta ishga tushiring va uchta chiqishni yana solishtiring. Xuddi shu tor qamrov bilan qaytgan child mahalliy fayl tomonidan emas, uzoq tomon tomonidan toraytirilmoqda va bu mahalliy tahrir emas, boshqa administrator bilan suhbat.

Siyosatlar ro'yxatida ikkala yo'nalishni o'qing, chunki bir yo'nalishni o'rnatib ikkinchisini o'rnatmaydigan tunnel sozlama kiyimidagi yo'naltirish muammosi. Oldinga va orqaga siyosatlar bir xil selektor juftini oynaviy shaklda nomlashi kerak va yo'q oyna selektor matnida emas, demon yoki taklifdagi nuqson.

Yo'naltirishni va qaytish marshrutini tekshiring

Selektor trafikni shlyuzgacha qabul qiladi, lekin shlyuzni uni keyinroq yo'naltirishga majburlamaydi. Yo'naltirish yoqilgan bo'lishi, firewall oqimga ruxsat berishi va javob mijozlar to'plamigacha qaytish yo'lini topishi kerak. Bular uch alohida talab va har biri boshqa alomat bilan muvaffaqiyatsiz bo'ladi. Yo'q yo'naltirish qoidasi qora tuynuk kabi ishlaydi, yo'q qaytish marshruti esa bir tomonlama tunnel kabi.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Xususiy mijoz manzillari odatda ommaviy interfeysdan chiqishdan oldin qasddan manba tarjimasini talab qiladi, ochiq yo'naltirilgan taqsimot esa boshqacha ishlovni talab qiladi. Agar NAT ishtirok etsa, amalga oshirish qo'llab-quvvatlaydigan istisnolarni saqlang, shunda xavfsizlik siyosati tekshirishi kerak bo'lgan trafik undan chetlab tarjima qilinmaydi. Boshqa shlyuzdan ko'chirilgan keng masquerade qoidasi muallif mo'ljallaganidan ancha ko'p oqimni o'zgartiradi. Qoidani faqat mijozlar to'plami uchun yozing va nima uchun mavjudligini tushuntiruvchi izoh qoldiring.

Mijozda siz taxmin qilgan marshrutlarni emas, backend o'rnatgan marshrutlarni tasdiqlang. Marshrut o'rnatish o'chirilgan menejerga qo'lda saqlanadigan yo'naltirish loyihasi kerak va bu loyiha tunnel o'zgarganda har safar yangilanishi kerak. Marshrutlash jadvalini qayta ulangandan keyin tekshiring, faqat yangi yuklashdan keyin emas.

Tunnel hali nimani qamramayotganini tekshiring

Selektor jufti IPv4 ni qamraydi va boshqa hech narsani emas. IPv6, DNS va har qanday amaliy dastur darajasidagi siyosat alohida qarorlar bo'lib, keng IPv4 selektori ularni jimgina e'tiborsiz qoldiradi. Har bir IPv4 paketini tashiyotgan tunnel ham har bir nom qidiruvini sizdirishi mumkin.

Ko'zlangan DNS yo'lini aniq ayting, chunki nomlarni mahalliy hal qiluvchi orqali hal qiladigan to'liq tunnel so'rovlarni tunnel tashqarisiga sizdiradi va xususiy nomlarni buzadi. Agar mijozga IPv6 manzil berilsa, bu manzil oilasiga ham xuddi shunday ishlov kerak, aks holda host tunnel himoya qilmaydigan yo'lni afzal ko'radi. Faqat xususiy tomon javob bera oladigan nom bilan sinab ko'ring va ommaviy javobni sizib chiqish deb hisoblang.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Yuqoridagi ro'yxatdan kelishilgan selektorlar bilan birga shu ikki buyruq orqali zanjirni tasdiqlang. Agar traceroute mahalliy routerni birinchi sakrash sifatida ko'rsatsa, selektorlar nima deyishidan qat'i nazar trafik tunneldan foydalanmayapti. Internetga kirish faqat tanlangan trafik mo'ljallangan shlyuz orqali qabul qilinib, yo'naltirilib va qaytarilganda to'liq bo'ladi. Profilda 0.0.0.0/0 topish o'sha zanjirning boshlanishi, uning isboti emas.

O'xshash maqolalar