Kubernetes'dagi OpenVPN pod hech narsani uzatmayaptimi? ip_forward'ni tekshiring

Noutbukingiz yashil tunnel ko'rsatadi, mijoz jurnali marshrutlar yuborilganini bildiradi, va javob beradigan yagona manzil VPN serverining o'z tunnel IP-sidir. Undan narigi pinglar nima niyat qilsangiz ham o'ladi, u ClusterIP bo'ladimi, boshqa pod manzilimi yoki ochiq xost nomimi. Bu birikma noaniq emas, diagnostik: dekapsulyatsiya ishlaydi, ikkinchi sakrash esa yo'q.

Men bunga chart orqali o'rnatilgan OpenVPN obrazi ishlayotgan Debian tugunida duch keldim, tunnel esa oson qism edi. Mijoz 10.8.0.x lizingini oldi, 10.8.0.1 javob berdi, 10.96.0.10 esa, klaster DNS xizmati, vaqt tugashi bilan yakunlandi. Server jurnalida hech narsa kasal ko'rinmadi, va odamlar hech qachon tegish kerak bo'lmagan iptables qoidalarini qayta yozishni boshlashining sababi aynan shu.

VPN pod — router, va buni ochiq aytishga arziydi. Shifrlangan paketlar keladi, podning o'z tarmoq namespace'ida ochiladi, so'ng boshqa interfeys orqali chiqishi kerak. Linux bu ikkinchi qadamni aynan o'sha namespace ichida uzatish yoqilmaguncha rad etadi.

Mijoz nimaga yeta oladi va nimaga yeta olmaydi

Javob beradigan manzil tunnelning oxirgi nuqtasiga tegishli, VPN jarayoni esa uni lokal ravishda egallaydi, shuning uchun uzatish umuman ishtirok etmaydi. Qolgan hamma narsa, jumladan boshqa pod, xizmat VIP yoki internet, yadrodan paketni tun0 dan eth0 ga ko'chirishni talab qiladi. Bu ko'chirish rad etilganda, alomat rad etish emas, bir xil sukunat, chunki tunnel bo'ylab orqaga hech narsa ICMP xatosi yaratmaydi. Siz taym-autlar olasiz, yetib bo'lmaydi degan xabarlar emas, va bu hech kim umuman marshrutlamayotganining ishorasi.

Ikki daqiqalik tasnif qatlamni toraytiradi. Agar DNS nomlari muvaffaqiyatsiz bo'lsa, xizmat IP siga xom pinglar muvaffaqiyatli bo'lsa, muammo uzatishda emas, DNS quvurlarida. Agar peer manzilidan narigi har bir manzil taym-autga tushsa, yalang'och IP ham, namespace'dan boshlang.

Sozlamani namespace ichidan o'qing

Har bir pod o'z tarmoq namespace'ini oladi, va net.ipv4.ip_forward har bir namespace uchun sysctl. Uni tugunda o'zgartirish konteyner haqida hech narsa demaydi, va bu noto'g'ri mashinada tushdan keyin vaqt o'tkazishning ishonchli usuli.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

Nol tashxisni tasdiqlaydi. Qiymat tugunning ishlash vaqti konfiguratsiyasidan ham meros olmaydi: u har safar konteyner yaratilganda obrazning standartidan boshlanadi. Shuning uchun kubectl exec ... sysctl -w bilan qo'lda qo'llangan tuzatish keyingi qayta ishga tushirishda yo'qoladi va vaqti-vaqti bilan ko'rinadigan nuqson sifatida qaytadi.

Manifest saqlab qolishi uchun uni yoqish

Barqaror variant — xuddi shu pod sandbox'da ishlaydigan va VPN konteyneri boshlanishidan oldin qiymatni yozadigan init konteyner. Pod ichidagi konteynerlar tarmoq namespace'ini bo'lishadi, shuning uchun sozlama asosiy konteynerga o'tadi.

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

Aynan privileged: true — sharhlovchilar qarshi chiqadigan satr, va ular haq. sysctl yozish uchun yo imtiyoz, yo tor doiradagi qobiliyat kerak, va cheklangan Pod Security Standard bilan ishlaydigan klaster imtiyozli init konteynerni butunlay rad etishi mumkin. Agar admission podni rad etsa, buni yaratish paytida bilib olasiz, bu hech bo'lmaganda halol va o'qish oson.

Tozaroq alternativa — pod darajasidagi securityContext.sysctls ro'yxati, u kubelet'ga hech bir konteynerga imtiyoz bermasdan namespace'li sysctl qo'llash imkonini beradi. U faqat klasterni ruxsat ro'yxatidagi nomlarni qamrab oladi. net.ipv4.ip_forward o'sha ro'yxatdami yoki yo'qmi kubelet qanday sozlanganiga bog'liq, va undan tashqari sysctl so'ragan pod admission'da rad etiladi yoki sandbox qayta sinab ko'rilguncha CreateContainerConfigError da tiqilib qoladi. Maydon buzilgan deb o'ylashdan oldin ruxsat ro'yxatini tekshiring.

Ikkala yondashuvdan birini qo'lda qurishdan oldin, chart allaqachon kalitni ochib beradimi, qarang, ko'pincha ipForwardInitContainer: true kabi narsa sifatida. Chart qiymatidan foydalanish override faylingizni kichik saqlaydi va keyingi yangilanishdan omon o'tadi, qo'lda yamalgan Deployment o'zgarishlari buni qilmaydi.

Ikkinchi yarmi: qaytish yo'li va siyosat

Yoqilgan uzatish zarur, lekin yetarli emas. Agar mijozlar klaster tarmog'ida marshruti yo'q xususiy hovuzdan foydalansa, javoblar tunnelga qaytish yo'lini topa olmaydi, va pod o'sha trafikni o'z manzili tomon maskalashi kerak.

Siyosat buning ustida turadi. NetworkPolicy obyektlari va bulut firewall qoidalari paket tarjimadan keyin olib yurgan manba manziliga qarshi baholanadi, shuning uchun mijoz hovuzi uchun yozilgan qoida maskalash yoqilgandan keyin jimgina mos kelishni to'xtatishi mumkin.

Mijozlar faqat klaster ichidagi xizmatlarga yetishi kerak bo'lsa, VPN'ni xizmat VIP'ida tugatish pod tarmog'iga marshrutlashdan kichikroq dizayn. U mijoz hovuzini CNI marshrut jadvalidan butunlay tashqarida saqlaydi.

Muvaffaqiyatsiz sakrashni mijozdan ajratish

Tashqariga qarab ishlang va birinchi jim qadamda to'xtang. VPN peer'dan boshlang, so'ng qaysidir podning manzilini sinab ko'ring, so'ng xizmat VIP'ini, va shundan keyingina ochiq manzilni. Har bir muvaffaqiyat chegarani bir sakrashga suradi, va har bir muvaffaqiyatsizlik tekshirishga arziydigan qatlamni nomlaydi. Har qanday joylashtirishdan keyin exec bilan kirib sysctl'ni yana o'qing, chunki almashtirilgan pod obrazning standartidan boshlanadi, va manifestda hech qachon bo'lmagan tuzatish allaqachon ketgan.

Kubernetes hujjati klasterda sysctl ishlatish haqida qaysi nomlarni pod xavfsizlik konteksti orqali o'rnatish mumkinligini sanab o'tadi, va admission o'zgarishni rad etganda birinchi qarash kerak bo'lgan joy shu.