Ikki qatlamli VPN hovuzlari: strongSwan'da ikkala oilani ham qamrab olish

Shlyuz sayohatchi foydalanuvchiga IPv4 va IPv6 virtual manzillarini birga bera oladi, tashqi tunnel esa hali ham IPv4 ustidan yuradi. Bular mustaqil qarorlar bo‘lib, ularni bitta deb qabul qilish ikki qatlamli rejalar odatda buziladigan joydir. Mijozning ichki oilalari, u yetib bora oladigan himoyalangan prefikslar va inkapsulyatsiyani tashuvchi transport uch xil alohida tanlovdir.

Ko‘p chalkashlik ikki qatlamli so‘zini faqat bir joyda ikki qatlamli bo‘lgan dizaynga qo‘llashdan kelib chiqadi. Xizmat ichkarida ikki qatlamli, tashqi manzilida bir qatlamli bo‘lib, baribir mijozlar uchun juda yaxshi ishlashi mumkin. Qila olmaydigan narsasi tasodifan ishlashdir.

Ichkarida ikki oila, tashqarida bitta yo‘l

Tashqi ulanish UDP ustidagi IKE bo‘lib, mijoz qayerda bo‘lishidan qat’i nazar, o‘sha yerdan yetib borish mumkin bo‘lgan bitta manzil oilasini talab qiladi. Ichki IPv6 manzili IPv6 qo‘llab-quvvatlaydigan provayderni talab qilmaydi, chunki ichki paket tashqi paket ichidagi yukdir. Ko‘pgina ishlayotgan joylashtirishlar IPv6 prefikslarini faqat IPv4 bo‘lgan yuqori kanal orqali tashiydi.

Tashqi yo‘l haqiqatan cheklaydigan narsa yetib borish va NATdan o‘tishdir. Agar shlyuz faqat IPv4 manzilini e’lon qilsa, faqat IPv6 bo‘lgan tarmoqdagi mijoz qanday hovuzlar sozlamagan bo‘lsangiz ham umuman ulanmaydi. Tashqi oilani mijozlar auditoriyangizga qarab tanlang, ichki manzil rejasiga qarab emas.

Har bir oilada mijozga manzil bering

Ikkala oilani so‘rash mijoz tomonida bir qatorli bayonot, shlyuzda bo‘lishadigan narsa bo‘lsa. Nomlangan hovuzlar manbalarni xizmat tarmoqlaridan alohida tutadi va aynan shu xususiyat xavfsizlik devori qoidalarini olti oydan keyin ham o‘qiladigan qiladi.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Qiymat vips har bir oiladan bitta manzil so‘raydi, hovuzlar ro‘yxati esa bu manzillar qayerdan kelishini belgilaydi.strongSwan'ning virtual IP haqidagi hujjatlari bir nechta so‘rov va hovuz taqsimotini qamrab oladi, shu jumladan aniq manzil so‘rayotgan mijoz faqat javob beruvchi bekor qilishi mumkin bo‘lgan afzallikni bildiradi degan fikrni ham. Mijoz doim bir xil qiymat oladi deb hisoblaydigan kirish qoidasini qurmang.

Namunani ko‘chirish o‘rniga o‘zingizning noyob mahalliy prefiksingizni yarating. Ikkalasi ham fd42::/16 joriy qilgan ikki tashkilot birinchi marta bir-biriga ulanganda to‘qnashuvni topadi va buni diagnoz qilish yoqimli emas.

Selektorlar manzillarni tasvirlaydi, manbalarni emas

Bola SAning mahalliy trafik selektorlari shlyuz orqasida qaysi himoyalangan tarmoqlar turishini aytadi, masofaviy selektorlar esa mijoz manba sifatida nimadan foydalanishi mumkinligini tasvirlaydi. Virtual hovuz manzili o‘sha siyosatning manba tomoniga tegishli; uni manzillar ro‘yxatiga qo‘yish konfiguratsiyani keng tarqalgan noto‘g‘ri o‘qishdir.

Ikkala oila ham shlyuzda qaytish yo‘llari va ruxsat etilgan yo‘naltirishni talab qiladi. Hovuzga qaytish yo‘li bo‘lmagan holda selektorga prefiks qo‘shish o‘rnatiladigan, trafikning bir yo‘nalishini o‘tkazadigan va javobni jimgina tashlab yuboradigan tunnel hosil qiladi. Selektor siyosat, marshrutlash emas.

Hovuzlar va xizmat prefikslarini manzil rejangizning alohida bloklarida saqlang. Ular ustma-ust tushganda, himoyalangan hostga yetishi kerak bo‘lgan yo‘l hovuz manziliga mos kelib, tunnel ichida yo‘qolishi mumkin.

DNS va javob yo‘li bu tugallanganga o‘xshaydimi-yo‘qmi shuni hal qiladi

Rezolver javoblari rezolverga yetish uchun ishlatiladigan transportdan mustaqil. Nom A yozuvini, AAAA yozuvini yoki ikkalasini ham qaytarishi mumkin, mijoz esa o‘zining afzallik qoidalariga ko‘ra tanlaydi. Agar ichki xizmat AAAA yozuvini e’lon qilsa, lekin hech narsa bu prefiksni marshrutlamasa, ikki qatlamli tarmoqlardagi mijozlar avval IPv6 yo‘lini sinab ko‘radi va u muvaffaqiyatsiz bo‘lmaguncha shu yerda qoladi. Bu sodir bo‘layotganda tunnel konfiguratsiyasida hech narsa noto‘g‘ri ko‘rinmaydi.

Shuning uchun har bir nom uchun qaysi oilalar ishlatilishi mumkinligini hal qiling, so‘ng mos keladigan prefiks selektorda borligini va qaytish yo‘li borligini tekshiring. Bu har bir xizmat bo‘yicha qaror. Ikki turdagi yozuvlarni ajratmasdan e’lon qilish faqat IPv4 bilan ishlaydigan xizmatning yarim foydalanuvchilari uchun vaqt tugay boshlashining yo‘lidir.

Tugallangan deb atashdan oldin ikkala oilani tekshiring

Yuklanadigan konfiguratsiya ishlaydigan konfiguratsiya emas. Demon xabar bergan holatni o‘qing, hovuz taqsimotini tasdiqlang, so‘ng mijoz haqiqatan o‘rnatgan yo‘llarga qarang.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Birinchi ikki buyruq o‘rnatilgan bola SAlarni va qaysi hovuzlarda hali manzillar borligini ko‘rsatadi, shuning uchun birinchi mijoz uchun ishlab, o‘ninchida muvaffaqiyatsiz bo‘ladigan reja ko‘rinadi. Oxirgi ikkisi mijoz hovuzdan global IPv6 manzilini olganmi va himoyalangan prefiksga trafik aslida qayerga borishini ko‘rsatadi. Berilgan manzilni siz sozlagan hovuz bilan solishtiring, umid qilgan manzil bilan emas. Agar javob beruvchi o‘z siyosatiga ko‘ra boshqa qiymat tanlagan bo‘lsa, yo‘llar va xavfsizlik devori qoidalari baribir uning tanloviga mos kelishi kerak.

So‘ng har bir oila uchun bitta himoyalangan hostni va ikkalasiga ham hal bo‘ladigan nomni sinab ko‘ring. Bitta oila sinovi siz mashq qilmagan rejaning yarmi haqida hech narsa aytmaydi va yo‘qolgan yo‘l odatda o‘sha yarmida bo‘ladi.