Nima uchun macvlan konteyneri VPN mijoziga javob bera olmaydi

VPNni tugatadigan va shu bilan birga macvlan tarmog’ida konteyner ishga tushiradigan Linux xostini tasavvur qiling. LAN — 192.168.60.0/24, konteynerda 192.168.60.210 bor, VPN mijozlari esa 10.95.0.0/24 dan keladi. Mijoz xizmatga yetib boradi, javob hech qachon qaytmaydi va xostdagi har bir xavfsizlik devori qoidasi to’g’ri ko’rinadi. Bu alomatni ikkita alohida cheklov keltirib chiqaradi va bittasini tuzatish ikkinchisini joyida qoldiradi.

Ikki cheklov, bitta alomat

Birinchi cheklov — izolyatsiya: Dockerning macvlan drayveri konteynerga ota-ona interfeysi orqali o’z xosti bilan gaplashishga ruxsat bermaydi. Xost stegi va konteyner o’rtasidagi trafikning yo’li yo’q, xostdagi marshrutlar qanday yozilganidan qat’i nazar.

Ikkinchi cheklov — qaytish yo’li. Konteynerning standart shlyuzi odatda LAN routeri bo’ladi, shuning uchun VPN mijoziga yuborilgan javob shu router orqali chiqadi. Agar routerning VPN hovuziga qaytish marshruti bo’lmasa, javob o’rtada bir joyda tashlab yuboriladi.

Bu ikki nosozlik mijoz tomondan bir xil ko’rinadi: kelayotgan so’rov va hech qachon kelmaydigan javob. Ular turli tuzatishlarni talab qiladi va keng masquerade qoidasi qaysi biri hali buzuqligini yashirishi mumkin. Shuning uchun birinchi sinov xavfsizlik devoridagi yana bir o’zgarish emas, konteyner tomonidagi yozib olishdir. Agar so’rov u yerda hech qachon ko’rinmasa, izolyatsiya cheklovi amal qiladi.

Xost tomonidagi shimni tor qilib quring

Xostdagi bir xil ota-onaga ko’prik rejimida ulangan ikkinchi macvlan interfeysi xost stegiga shu LAN segmentida o’z shaxsiyatini beradi. U uchun DHCP hovuzidan tashqarida va konteyner diapazonidan tashqarida manzil ajratib qo’ying va faqat konteynerni u orqali o’tkazing.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Birinchi buyruq interfeysni ko’prik rejimida yaratadi, bu ushbu drayverning hujjatlashtirilgan standarti va xost-konteyner trafigi uchun kerakli rejimdir. Ikkinchisi /32 ajratadi, manzil LAN prefiksi bilan to’qnashmasligi uchun, to’rtinchisi esa shim orqali faqat konteyner manzilini yuboradi.

Butun LANni yangi interfeys orqali yo’naltirmang. Oddiy ulangan marshrut o’z holicha qoladi, xost marshruti esa ataylab tor bo’lib, bitta konteyner yo’l oladi, segmentning qolgan qismi xatti-harakatini o’zgartirmaydi. Shimga qaragan standart marshrut boshqa oqibatlarga ega boshqa loyiha bo’lardi. Uni aniq tuting, zarar radiusi kichik bo’lib qoladi.

Bu buyruqlar ishlayotgan xostdagi tarmoq sozlamalarini o’zgartiradi. Qurilma yoki boshqariladigan platformada shu platformaning qo’llab-quvvatlanadigan konfiguratsiya mexanizmidan foydalaning, chunki root-shell ichidagi interaktiv o’zgarish yangilanishdan keyin saqlanmasligi mumkin.

Manba qanday saqlanishini hal qiling

Shim joyida bo’lganda konteyner xostga yetib boradi va javob qaysi manba manzilini olib yurishi savolga aylanadi. Asl VPN manbasini saqlash tozaroq model: konteyner mijozning haqiqiy manzilini ko’radi, xizmatning jurnallari va kirish qoidalari esa undan foydalana oladi.

Bu ishlashi uchun konteynerning tarmoq konfiguratsiyasi ushbu yo’l uchun 10.95.0.0/24 trafigini 192.168.60.250 ga o’z shlyuzi sifatida yuborishi kerak. Bu konteynerning o’z konfiguratsiyasi ichidagi qo’llab-quvvatlanadigan marshrut yoki shlyuz sozlamasi, xost tomonidagi hiyla emas. Uni konteyner ichidan tasdiqlang, sozlama kuchga kirgan deb faraz qilmang. Hali ham LAN routeriga qaragan standart shlyuz javoblarni o’sha teshikka yuborishda davom etadi.

Agar tasdiqlangan loyiha buning o’rniga VPN manbalarini yashirsa, tarjimani tor doirada cheklang: haqiqiy VPN hovuzi, chiquvchi interfeys sifatida shim, va aniq konteyner hamda xizmat.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Shimni chiquvchi interfeys sifatida moslashtiring, tunnelni emas. Tunnelni chiquvchi interfeys deb ataydigan qoida konteyner tomon ketayotgan paketga mos kelmaydi va bunday sozlashlarda odatda aynan shu xato bo’ladi. Qoidani yuqoridagi gapdek tor tuting va hovuz o’zgarganda uni qayta ko’rib chiqing.

Mijozdan tekshiring, xostdan emas

Xostning o’zidan shim manziliga bog’langan so’rov shim konteynerga yetib borishini isbotlaydi. Ammo konteyner saqlangan 10.95.0.x manbasiga trafikni qaytara olishini isbotlamaydi, chunki bu sinovdagi manba manzili shimning o’ziniki.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Birinchi buyruq xostdan konteynergacha bo’lgan qismni sinaydi, ikkinchisi esa haqiqiy VPN mijozi so’rov yuborayotganda shimdan aslida nima o’tishini ko’rsatadi. Kirish yo’lidagi manba manziliga va o’sha oqim bilan javob paydo bo’lishiga e’tibor bering.

Xostda uzatish yoqilgan bo’lishi kerak, uzatish yo’li esa xizmat portida VPN hovuzidan shimga ruxsat hamda o’rnatilgan javoblar uchun ruxsat talab qiladi. Xostdagi INPUT qoidasi uzatilayotgan trafikka ruxsat bermaydi va bu marshrutlash to’g’ri ko’ringandan keyin paket tashlab yuborilishining keng tarqalgan sababidir.

Haqiqiy ilovani haqiqiy hisob ma’lumotlari bilan ishga tushiring, so’ngra o’sha konteynerdagi ikkinchi, aloqasiz xizmat sizni hali ham rad etishini tekshiring. Agar uni ishga tushirishning yagona yo’li barcha uzatish qoidalarini ochish bo’lsa, loyiha tugallanmagan. Xizmat qaysi manba manzilini qayd etganini ham yodda tuting, chunki bundan buyon uning o’z kirish qoidalari shundan foydalanadi.