SaaS trafigini to'g'ri mijoz VPN-iga qanday yo'naltirish kerak
Ustma-ust tushadigan mijoz quyi tarmoqlari umumiy marshrutlashni buzadi. Izolyatsiya modelini tanlang, har bir ishni tasdiqlangan ijarachiga bog'lang va ishga tushirishdan oldin ijarachilar orasidagi yo'llarni sinab ko'ring.
SaaS platformasi o'n ikkita mijoz tarmog'iga ulanadi, va bu mijozlardan ikkitasi o'zlarining asosiy ma'lumotlar bazasi uchun 10.20.0.10 dan foydalanadi. Ishda bu manzilni olgan ishchi ish qaysi ma'lumotlar bazasini nazarda tutayotganini bilishning hech qanday yo'li yo'q, va umumiy marshrutlash jadvali uni prefiks ko'rsatgan tunnelga xursandchilik bilan yuboradi. Yechim ko'proq tunnel emas; yechim ijarachi identifikatori yo'lga qayerda kirishini va manzil rejasi qanday izolyatsiya modelini talab qilishini hal qilishdir. Uch shart tanlovni hal qiladi: mijoz prefikslari ustma-ust tushadimi, xato qanchalik uzoqqa tarqalishi mumkin va konnektorni kim boshqaradi.
Ikki mijoz ma'lumotlar bazasi, bitta maqsad manzili
IP manzili bu joy, identifikatsiya emas. So'rov server tasdiqlagan ijarachini olib yurishi kerak, va bu ijarachi maqsad hal qilinishidan oldin tarmoq kontekstini tanlashi kerak.
Bu sodir bo'lmaganda, nosozlik jim. Ulanish muvaffaqiyatli bo'ladi, so'rov ishlaydi, va javob noto'g'ri mijozning ma'lumotlar bazasidan keladi, chunki marshrutlash jadvalida 10.20.0.10 uchun bitta yozuv bor edi. DNS vaziyatni yomonlashtiradi: ijarachi A kontekstida hal qilingan keshlangan nom ijarachi B uchun ishlayotgan ish tomonidan qayta ishlatilishi mumkin. Paketda hech narsa ikkalasini ajratmaydi, shuning uchun hech qanday qayta urinish mantiqi buni tuzatmaydi.
Avval izolyatsiya modelini hal qiling
Mahsulotlarni taqqoslashdan oldin uch shartni yozing. Ustma-ust tushish bitta manzil maydonini umuman bo'lishish mumkinligini hal qiladi; ta'sir radiusi marshrutlash xatosi qo'llab-quvvatlash chiptasimi yoki buzilishmi ekanligini hal qiladi; operatsion egalik har bir ijarachi uchun konnektor flotini boshqara olasizmi yoki yo'qmi hal qiladi.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
Agar prefikslar farq qilsa va siyosat boshqariladigan hubga ruxsat bersa, har bir ijarachi uchun marshrutlash jadvallari bilan bitta Transit Gateway amalga oshirilishi mumkin. Ilova assotsiatsiyasi o'sha ilovadan kiradigan trafik uchun ishlatiladigan marshrutlash jadvalini tanlaydi, tarqatish esa jadvalda qaysi yo'llar paydo bo'lishini tanlaydi. Faqat o'z jadvaliga bog'langan va faqat o'z prefikslarini tarqatadigan ijarachi ilovasi hubga yetadi va boshqa joyga yetmaydi. Bu marshrutlash qarori, va hech kim umumiy jadvalga standart yo'l qo'shmaguncha to'g'ri bo'lib qoladi.
Agar prefikslar ustma-ust tushsa, faqat marshrutlash ularni ajrata olmaydi. Sizga har bir ijarachi uchun alohida tarmoq konteksti yoki har bir mijozning maydoniga aniq ma'no beradigan tarjima rejasi kerak.
Transit Gateway izolyatsiyasi aslida nimani anglatadi
Assotsiatsiya va tarqatish muhim ikkita sozlamadir, va ularni chalkashtirish oson. Assotsiatsiya ushbu ilovadan kelgan paket qaysi jadvaldan qidirilishini javob beradi; tarqatish esa qaysi jadvallar ushbu ilovaning yo'llarini o'rganishini javob beradi. Izolyatsiya ikkalasini ham ijarachiga xos qilishdan kelib chiqadi, ko'proq ilovalar yaratishdan emas.
Standart hamma-hammaga sozlama qulay va izolyatsiya emas. Alohida marshrutlash jadvallari ulanishni cheklaydi, lekin bitta o'zgarmagan maqsad manziliga bir xil marshrutlash kontekstida ikkita ma'no bermaydi. Agar dastur ijarachini bilishdan oldin 10.20.0.10 ni hal qilsa, marshrutlash qatlami kerakli ma'lumotni allaqachon yo'qotgan.
AWS 2026-yil 23-oktabrda Transit Gateway va Cloud WAN uchun ilova darajasidagi 1:1 NAT qo'shdi, bu qo'llab-quvvatlanadigan ilovalar uchun ustma-ust tushish javobini o'zgartiradi. Transit Gateway NAT hujjatlari xost bitlari saqlangan holda statik, holatsiz, teng prefiksli IPv4 xaritalashlarini tavsiflaydi. Bu asosida loyihalashdan oldin qo'llab-quvvatlanadigan ilova turlari va mintaqaviy cheklovlarni tekshiring.
Ishni tasdiqlangan ijarachiga bog'lang
Har bir ish server tomonidan tasdiqlangan ijarachi identifikatorini olib yurishi kerak, va bu identifikator administratorga tegishli ulanish yozuvini tanlashi kerak. Yozuv tasdiqlangan tarmoq kontekstini, xizmat manzilini, hisob ma'lumotlari havolasini va u yerda ruxsat etilgan amallarni nomlaydi. Ishonchsiz so'rov hech qachon o'zining VPN identifikatori, shlyuzi yoki shaxsiy maqsadini taqdim etmasligi kerak, chunki haqiqiy kirish har bir ulangan mijozning manzil maydonini tekshirish ruxsati emas.
Izolyatsiyalangan konnektorlar dizaynida ijarachi A ishi A VPCsida ishlaydigan va faqat A tasdiqlangan resurslariga yeta oladigan A ga xos konnektorga boradi. Bitta xostdagi alohida konteynerlar bu ajratishni o'z-o'zidan yaratmaydi; tarmoq nomlar fazosi, yo'llar va chiqish siyosati uni amalga oshirishi kerak. Konnektorga ijarachi bilan cheklangan hisob ma'lumotlari va navbatlar ham kerak, chunki shaxsiy yo'l umumiy sirni yoki umumiy ish elementini cheklamaydi. Birlashtirilgan dastur ishchilari, tarmoq konteksti va hisob ma'lumotlari xostga emas, ijarachiga tanlansa yaxshi.
Salomatlik tekshiruvlari ijarachi va bosqichni nomlashi kerak: tunnel o'rnatildi, yo'l mavjud va haqiqiy xizmat so'rovi muvaffaqiyatli bo'ldi — bu uch xil signal. Ishlab turgan tunnellarning umumiy soni konnektori buzilgan yagona mijozni yashiradi.
Muvaffaqiyatsiz bo'lishi kerak bo'lgan yo'llarni sinab ko'ring
Ishga tushirishdan oldin uchta test o'tkazing. Ruxsat etilgan A amali muvaffaqiyatli bo'lishi kerak, ruxsat etilgan B amali muvaffaqiyatli bo'lishi kerak, va ataylab B ning konnektoriga yoki tarjima qilingan taxallusiga yo'naltirilgan A ishi yopiq tarzda muvaffaqiyatsiz bo'lishi kerak. So'ngra bitta tunnelni uzib, ish faqat shu ijarachi uchun muvaffaqiyatsiz bo'lishini va boshqa mijozning bir xil raqamli quyi tarmog'iga tushmasligini tasdiqlang. Tiklash ham sinovdan o'tkazilishi kerak, chunki eskirgan yo'l yoki keshlangan hisob ma'lumotlari uzilishdan uzoq yashashi mumkin.
Arxitektura izolyatsiyalangan konnektorlari bo'lgan birlashtirilgan ishchilar yoki butunlay alohida ijarachi resurslari bo'lishi mumkin. Invariant bir xil: tasdiqlangan ijarachi konteksti yo'l va hisob ma'lumotlarini tanlaydi, va hech qanday yo'l o'zgarishi dasturga ijarachilar o'rtasida ruxsat bermaydi.