SSH orqali mahalliy serverga kiring, tunnelni ko’taring va xususiy VM javob beradi; so’ng Google API ga birinchi chaqiruv marshrutsiz muvaffaqiyatsiz tugaydi. VM subneti va API VIP manzillari turli manzillar, shuning uchun biriga bo’lgan marshrut ikkinchisini tanlamaydi. Xususiy API chaqiruvi ishlashi uchun uch shart bajarilishi kerak. API nomi VIP ga hal bo’lishi, VIP prefiksi tunnel orqali e’lon qilinishi va VPC javobni qanday qaytarishni bilishi kerak. Ping bu haqda hech narsa aytmaydi, subnetdagi mashinaga ishlaydigan SSH sessiyasi ham aytmaydi.

API ning VIP manzillari alohida manzillar

Google mahalliy tarmoqdan API ga kirish uchun maxsus VIP manzillarni e’lon qiladi va API nomlari uchun DNS aynan shu manzillarni qaytarishi kerak. Ikkalasi ham kichik prefiks va hech biri RFC 1918 fazosi emas:

RecordResolves toWhat it does not give you
private.googleapis.com199.36.153.8/30, the general front door for Google APIsnot a bypass around a service perimeter
restricted.googleapis.com199.36.153.4/30, reachable only for services a perimeter allowsnot the whole API surface, so some names stay out of reach

Ommaviy ko’rinadigan manzillar marshrut tunneldan chiqishi kerak degani emas oddiy internet uchun. Bu prefikslar mahalliy mijoz ixtiyoriy chiqish nuqtasi o’rniga qo’llab-quvvatlanadigan yo’l orqali Google ning old qismlariga yetishi uchun mavjud. Ularni tunnelga tegishli manzillar deb biling, tekshiriladigan hostlar deb emas. Internet chiqishi uchun yozilgan firewall qoidasi ularni odatda tashlab yuboradi va bu chaqiruv boshlanishidan oldin muvaffaqiyatsiz bo’lishining keng tarqalgan sababi.

Qaysi endpointga yetishingizni DNS hal qiladi

Mahalliy hal qiluvchini tanlangan endpoint uchun Google hujjatlashtirgan yozuvlarga yo’naltiring, shunda ilovaga kerak bo’lgan nomlar shu VIP bilan javob beradi. Faqat googleapis.com qilish ro’yxat emas: paket registrlari, konteyner registrlari va migratsiya konnektorlarining o’z hujjatlashtirilgan nomlari bor. Cheklangan VIP ham har bir xizmatni tashimaydi, shuning uchun hal bo’lgan nom hali ham qo’llab-quvvatlanmasligi mumkin. Hal qiluvchiga tegishdan oldin ilova haqiqatda bog’lanadigan domenlarni yozib qo’ying.

Xizmat nomi o’rniga VPC dagi VM manzilini taxmin qilish tuzatish emas va u odatda DNS bo’shlig’ini boshqa mijoz muvaffaqiyatsiz bo’lgunga qadar yashiradi.

VIP prefiksini e’lon qiling, qolganini saqlang

BGP ga asoslangan ulanishda Cloud Router tanlangan VIP prefiksini e’lon qilishi kerak, shunda mahalliy router bu diapazonni mo’ljallangan sessiya orqali o’rganadi. Faqat VPC subnetlarini e’lon qilish bu diapazonni qo’shmaydi va mahalliy router bu manzillar uchun standart yo’lini ishlatishda davom etadi. Marshrutlash jadvalidagi prefiks e’lon sessiyadan o’tganining yagona isboti.

Yangisini qo’shayotganda mavjud e’lonlarni saqlang, chunki router darajasi va peer darajasidagi variantlar qamrovi boshqacha, to’plamni almashtirish esa allaqachon ishlagan tarmoqlarni qaytarib olishi mumkin. So’ng samarali e’lonni butun routerda emas, har bir sessiyada tekshiring. Yo’qolgan prefiks va qaytarib olingan prefiks mahalliy tomondan bir xil ko’rinadi, shuning uchun o’tkazib yuborishni regressiyadan ajratadigan narsa sessiya ko’rinishidir.

VPC tomoniga o’z marshruti va qaytish yo’li kerak

VPC ichida VIP yo’li keyingi hop sifatida standart internet shlyuzidan foydalanishi kerak va nomiga qaramay bu trafik Google tarmog’ida qoladi. VPC ga VPN orqali mahalliy manbaga qaytish marshruti ham kerak va bu e’lon qilingan prefikstdan alohida obyekt. Tunnel va mijoz bir mintaqada bo’lmasa, hujjatlashtirilgan mintaqaviy marshrutlash talablarini hisobga oling.

Qaytish yo’lini mustaqil tekshiring, chunki ishlaydigan so’rov yo’nalishi buzilgan javob yo’nalishini yashirishi mumkin. Ikki yo’nalish, ikki marshrut va har biri o’z belgisi bilan muvaffaqiyatsiz tugaydi.

So’rovni sinang, so’ng rad etishni o’qing

ICMP aks sadosi bu VIP lardan javob olmaydi, shuning uchun muvaffaqiyatsiz ping hech narsani isbotlamaydi, muvaffaqiyatlisi juda ozini. Haqiqiy mijozdan nomning javobini va tanlangan marshrutni tekshiring, so’ng sizga muhim xizmatga ruxsat etilgan HTTPS so’rovini yuboring. So’rov xizmatga yetib, rad etilsa, hisob ma’lumotlari, IAM va amaldagi xizmat perimetri siyosatini ko’ring.

Xususiy marshrutlash API ruxsatini bermaydi va shaxs nima qilishga haqli ekanini o’zgartirmaydi. Tashish muvaffaqiyati va ruxsat etilgan javob alohida natijalar va ikkalasi ham kerak. IPv6 yo’lini ham aniq tuting, chunki IPv4 prefikslarini sozlash IPv6 ni afzal ko’radigan mijoz haqida hech narsa demaydi.

Google ning mahalliy tarmoqdan Private Google Access bo’yicha qo’llanmasi DNS yozuvlari va marshrutlash talablarini birga qamrab oladi, shuning uchun hal qiluvchi va e’lon sozlamalaringizni forum posti bilan emas, shu qo’llanma bilan solishtiring. So’ng o’sha so’rovni qayta ishga tushiring va javob hamda marshrutni o’sha chiptada qayd eting.

O'xshash maqolalar