Kubernetes ichida VPN mijozi IP-si: uni saqlaymizmi yoki SNAT qilamizmi?
Kubernetes ichida VPN mijozining haqiqiy manzilini saqlash va manba NAT o'rtasida uchta shart asosida tanlang, so'ng qaytish yo'lini va pod almashinuvini tekshiring.
Tunnel va backend o'rtasida qayerdadir mijoz manzili yo omon qoladi, yo almashtiriladi va ikkala natija ham himoyalanadigan. Tanlov qabul qiluvchi xizmat egasiga tegishli, CNI o'rnatgan kishiga emas. Har bir mijoz bo'yicha avtorizatsiya, kvotalar yoki audit yozuvlari muhim bo'lganda, manzil har bir sakrashdan o'tishi kerak. Umumiy nisbatlash maqbul bo'lganda, manba NAT aks holda abadiy saqlab turishingiz kerak bo'ladigan marshrutlash muammosini yo'q qiladi.
Mijoz manzili aslida qayerda yo'qoladi
Uzoq mijozning paketi VPN podga tunnel diapazoni ichidagi ichki manba bilan yetib boradi, aytaylik 10.90.0.42. Pod bu paketni ClusterIP yoki pod IP tomon uzatganda, uch xil mexanizm manbani qayta yozishi mumkin. Tugunning CNI masquerade qoidasi pod klaster CIDR-dan tashqariga yuboradigan trafikni qamrab oladi. Manzil tugundagi kube-proxy conntrack yozuvi Service sakrashining o'zini qamrab oladi. Ulanishni tugatuvchi proxy paketni umuman uzatmaydi, shuning uchun oxirida ko'rgan manba proxyga tegishli.
Ularning har biri boshqa qatlamda yashaydi, shuning uchun bitta Service maydoni deyarli hech qachon butun yo'lni tuzatmaydi.
VPN ning ommaviy Service'ida externalTrafficPolicy faqat tashqi ulanish taqdirini hal qiladi: Local uzoq manzilni uni qabul qilgan tugunda saqlaydi, Cluster esa kube-proxy paketni boshqa tugunga berib, o'sha yerda masquerade qilishiga ruxsat beradi. Bu sozlama mijozlaringiz ulanadigan listener'ni boshqaradi. VPN jarayoningiz keyin klasterga yo'naltiradigan shifri ochilgan paket haqida hech narsa demaydi.
Bahsni hal qiladigan uchta shart
Bu masala ko'tarilganda har safar o'sha uch savolni o'sha tartibda beraman, chunki birinchisi odatda bahsni tugatadi. Ularga aniq ish yuki uchun javob bering, butun klaster uchun emas. Bitta kompaniya ichidagi ikki klaster turli javoblarga kelishi mumkin va ikkalasi ham to'g'ri bo'lishi mumkin.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Agar backend birinchi savolga ha, ikkinchisiga yo'q deb javob bersa, sizda manifest tahrirlash emas, tarmoq ishi bor. Agar uchinchi qator proxy desa, manzil hech qachon omon qolmasdi va buning aksini da'vo qilish bir hafta paket tutishga arziydi.
preserve rejimi tarmoqdan nima talab qiladi
Manbani saqlash manzil tugun trafikni faol VPN shlyuzi orqali 10.90.0.42 ga qaytarishi kerakligini bildiradi. VPN hovuzi klaster CIDR emas, shuning uchun hech bir CNI uni siz uchun sukut bo'yicha marshrutlamaydi. Marshrutni o'zingiz qo'shasiz, so'ng u ishora qiladigan shlyuz so'nggi nuqtasi qayta rejalashtirishdan omon qolishiga ishonch hosil qilasiz.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Keyingi sakrash pod manzili, pod manzillari esa ko'chib yuradi. Marshrutni Service VIP yoki joyida qoladigan tugun manziliga qarating, yoki har bir chiqarib yuborishdan keyin shlyuz orqasidan quvishingizni tan oling. Teskari yo'l filtrlash boshqa tuzoq: qat'iy rejim kelgan interfeysga mos kelmaydigan qaytish yo'liga ega paketlarni tashlaydi va bu aynan saqlangan VPN oqimining shakli.
Bo'shashgan tekshiruv ko'pincha ishlaydigan qaytish yo'li bilan backenddan chiqqandan keyin yo'qoladigan javoblar o'rtasidagi farqdir. VPN tugunidagi masquerade qoidalari ham tunnel diapazonini chiqarib tashlashi kerak, aks holda uzatilgan paket qanday marshrut qurganingizdan qat'i nazar pod manzili bilan chiqadi. Bu istisnoni iptables'ni qo'lda tahrirlash o'rniga CNI ning o'z konfiguratsiyasida ifodalashni afzal ko'ring, chunki agent qayta ishga tushganda zanjirlarini qayta yozadi va qo'lda yozgan qoidangiz aynan keyingi yangilanishgacha yashaydi.
NetworkPolicy kirish nazorati, marshrutlash emas. Siyosatni qattiqlashtirish masquerade allaqachon almashtirgan manzilni hech qachon tiklamaydi.
SNAT qancha turadi va uni qanday yozib qo'yish kerak
Klasterga qarab manba NAT arzonroq dizayn va bu xato emas. Backend VPN pod yoki tugun manzilini ko'radi, jurnallar bir-biriga mos keladi va hech qanday qaytish marshruti bo'lishi shart emas. Siz yo'qotadigan narsa ikki mijozni tarmoq qatlamida ajratish qobiliyati, shuning uchun kvotalar, taqiqlar va audit izlari boshqa joydan kelishi kerak.
Odatda o'sha boshqa joy bu ilova: sessiya tokeni, imzolangan sarlavha yoki siz boshqaradigan proxy yozadigan PROXY protokoli satri. Bular qabul qiluvchiga faqat proxy yo'lda bo'lganda va sarlavhani mijoz tomonidan o'rnatib bo'lmaganda ishonish mumkin bo'lgan shaxsni beradi. Runbookda qaysi biri amal qilishini aniq yozing, chunki keyingi muhandis jurnaldagi manzilni mijoz deb o'ylaydi. Unday emas va bitta hodisa bu taxminni qimmatga aylantirish uchun yetarli.
Almashinuv yozib qo'yilgan ekan, halol bo'lib qoladi.
Ishlaydigan yo'lni omadli yo'ldan ajratadigan tekshiruvlar
Keshlangan ulanish bilan emas, yangi ulanish bilan sinab ko'ring va ikkala yo'nalishda ham sinang. Bir nechta nosozlik faqat yangi oqimlar qayta yozilgan yo'ldan o'tgani uchun oraliq ko'rinadi.
Bitta ruxsat etilgan so'rov davomida tuple'ni uch nuqtada tutib oling: dekapsulyatsiyadan so'ng darhol, VPN pod ning chiqish interfeysida va backendda. Agar manba ikkinchi va uchinchi tutish o'rtasida o'zgarsa, sabab pod ostida. Agar ikkinchisidan oldin o'zgarsa, podning o'zi tarjima qilmoqda.
Keyin VPN podni o'chiring va qayta rejalashtirilayotganda testni takrorlang. Chiqarib yuborishda buziladigan saqlangan yo'l tugallanmagan, endi mavjud bo'lmagan manzilga bog'langan NAT qoidasi ham shunday. Nihoyat, rad etilishini kutgan manbadan bitta so'rov yuboring va rad javobi yetishmayotgan marshrutdan emas, siyosatdan kelishini tasdiqlang.