VPC ga VPN ishlaydi, ammo boshqariladigan xizmat vaqti tugaydi
Tunnel sizning chekkangizda tugaydi, provayderning old eshigida emas. Marshrutni o'zgartirishdan oldin maqsadni VMda joylashgan, VPC ga ulangan yoki faqat ochiq deb tasniflang.
VPN orqali boshqariladigan ma'lumotlar bazasiga yetish odatda hech kim qo'llanmaga yozmagan sabab bilan muvaffaqiyatsiz bo'ladi: tunnel tarmog'ingizning chekkasida tugaydi, xizmat esa hech qachon uning sizning tomoningizda bo'lmagan. Marshrutlar jadvali to'g'ri ko'rinadi, tunnel ishlayotganini bildiradi, va ulanish baribir vaqti tugaydi. Quyidagi to'rtta tekshiruvni tartib bilan bajaring va o'tish sharti bajarilmaydigan birinchi tekshiruvda to'xtang, chunki undan keyingi har bir tekshiruv avvalgilari o'tgan deb hisoblaydi.
Birinchi tekshiruv: oxirgi nuqta aslida qayerda yashaydi?
VPN shlyuzi manzilini o'zingiz boshqaradigan ikki tarmoqni bog'laydi. Boshqariladigan xizmat provayderning o'z old eshigi orqasida ishlaydi va bu eshik mahsulotga qarab uchta shakldan birini oladi. Qaysi shakl bilan ishlayotganingizni bilmasangiz, hech qanday marshrut ishi yordam bermaydi, chunki nosozlik marshrut nosozligi bo'lmasligi mumkin.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
Behuda o'tgan tushlikdan keyingi vaqtlarning ko'pchiligi bu tasnifni chetlab o'tib, to'g'ri marshrutlar jadvaliga borishdan kelib chiqadi. Provayderda joylashtirilgan ochiq oxirgi nuqtaga ega xizmat diagramma nima desa ham sizning tunnellingiz orqasida emas, VPC ga ulangan xizmat esa hech qachon ochiq DNS javobida ko'rinmaydi.
Ikkinchi tekshiruv: VPC ga ulangan xizmat, masalan ElastiCache
Bunday keshlar o'z VPC ingiz ichida manzillanadi va ularning internetga qaragan tinglovchisi umuman yo'q. Xuddi shu VPC da tugaydigan mijoz VPN ularga yeta oladi, lekin faqat uchta shart bir vaqtda bajarilganda. Keshning oxirgi nuqtasi tunnellingiz ko'radigan quyi tarmoqlarga ulangan bo'lishi kerak, uning xavfsizlik guruhi mijozlaringiz keladigan manzilga ruxsat berishi kerak, va mijoz tomonida kesh quyi tarmoqlarini qamrab oluvchi marshrut bo'lishi kerak.
Odatiy xato — yaqin joydagi ulanish ham hisobga olinadi deb o'ylash. VPN ni boshqa VPC ga ulash yoki faqat peering ga tayanish keshning xavfsizlik guruhini yoki uning quyi tarmog'i marshrutlar jadvalini mijozlaringizga kengaytirmaydi. Mavjud tunnel boshqa joyda tugasa, shu VPC ichida joylashtirilgan sakrash xosti yoki VPN serveri odatiy zaxira variant bo'ladi. Bunday zaxira variant loyiha emas, aylanma yo'l, va qo'llanmada shunday belgilanishi kerak.
Uchinchi tekshiruv: ochiq nomli PaaS oxirgi nuqtasi
Azure Database for PostgreSQL ochiq server nomini taqdim etadi. U sizga hosts faylida mahkamlash va shlyuz orqali yo'naltirish mumkin bo'lgan xususiy manzil bermaydi. Virtual tarmoq xizmati oxirgi nuqtalari qaysi quyi tarmoqlar resursga yeta olishini cheklaydi; ular VPN orqali keladigan mahalliy mijozga ruxsat bermaydi.
Xususiy ruxsat olish degani xususiy oxirgi nuqta yoki xususiy ulanish loyihasini kiritish, so'ngra ochiq nom internet o'rniga shu nuqta bilan javob berishi uchun xususiy DNS zonasini qo'shish. VPN ning xizmat oxirgi nuqtasi qoidasi bilan birikmasi faqat diagrammada o'xshash bo'lgan boshqa arxitektura. App Service xuddi shu mantiqni qarama-qarshi yo'nalishda davom ettiradi: VNet integratsiyasi ilovaga VNet ichiga chiquvchi qo'ng'iroqlar qilish imkonini beradi va sizning tunnellingizdan kiruvchi xususiy yo'l yaratmaydi. Shuning uchun kiruvchi xususiy ruxsat xususiy oxirgi nuqta, App Service muhiti yoki ilova oldidagi shlyuzni talab qiladi, va ulardan qaysi birini ishlata olishingiz rejaga bog'liq.
To'rtinchi tekshiruv: o'z old eshigiga ega mahsulotlar
Firebase Hosting ni Cloud VPN ga ulash mumkin emas, chunki joylashtirish qatlami global old qism bo'lib, loyiha VPC si ichidagi narsa emas. Hujjatlashtirilgan alternativa boshqariladigan kirish nuqtasini o'zingiz qurish, proksi nusxasi yoki chelakka tayangan yuk balanslagichi bilan. Qanday bo'lsa ham sayt sof joylashtirish mahsuloti bo'lishdan to'xtaydi va endi siz boshqaradigan infratuzilmaga aylanadi. Bu almashinuvni kimdir tunnel uni qamrab oladi deb va'da qilishidan oldin nomlash arziydi.
Private API Gateway VPC xizmatlari tomoniga yaqinroq turadi: interface turidagi VPC oxirgi nuqtasi javoblari xususiy manzillar bo'lgan xost nomini e'lon qiladi, va sizning binolaringizdan trafik tunnel yoki maxsus ulanish orqali keladi. Oxirgi nuqta API ga ulangan bo'lishi kerak, sertifikat va xost nomi esa qo'ng'iroq qiluvchilar ishlatadigan moslashtirilgan domenga mos kelishi kerak.
Google Cloud VPN tunnellari nomlarga emas, hamkor IP manzillariga bog'lanadi. DNS uzatish alohida sozlanadi, shuning uchun tunnel to'liq sog'lom bo'lishi mumkin, ammo uzoqdagi xususiy zonada qidiruvlar baribir muvaffaqiyatsiz bo'ladi.
Keyin chegarani toping
Xuddi shu ulanishni VPC ichidagi VM dan ishga tushiring. U yerda muvaffaqiyatli bo'lib, VPN mijozidan muvaffaqiyatsiz bo'lsa, bo'shliq mijoz yo'li bilan xizmatning oxirgi nuqtasi orasida: marshrut, xavfsizlik guruhi, oxirgi nuqta siyosati yoki nom. Ikkala urinish ham muvaffaqiyatsiz bo'lsa, bu tarmoqda hech narsa xizmatga yeta olmaydi va VPN hech qachon to'siq bo'lmagan.
getent hosts db.internal.example
nc -vz db.internal.example 5432Nom qidiruvini va port tekshiruvini alohida bajaring, chunki ular turli sabablarga ko'ra muvaffaqiyatsiz bo'ladi va bu juftlik yo'lning qaysi yarmi buzilganini aytadi. Ochiq manzilga hal bo'ladigan nom sizga xususiy DNS zonasi ishlamayotganini aytadi.