VPNdagi noutbukdan xususiy Cloud SQL instansiyasiga yetib borishning ikkita oqilona yo‘li bor. Birinchisi — sizda allaqachon mavjud yo‘nalish orqali instansiyaning xususiy manziliga to‘g‘ridan-to‘g‘ri ulanish. Ikkinchisi — loopbackda tinglaydigan va Cloud SQLga ulanishni o‘zi ochadigan Cloud SQL Auth Proxy. Bular raqobatchi mahsulotlardan ko‘ra «hisob ma’lumotlarini kim ushlab turadi va yo‘nalishni kim ushlab turadi» degan savolga ikki xil javob. Noto‘g‘ri tanlov odatda tarmoq xatosi kabi o‘qiladigan avtorizatsiya xatosi sifatida namoyon bo‘ladi.

Mana jamoa oldiga qo‘yadigan taqqoslash, so‘ngra haqiqatan hal qiladigan tekshiruvlar.

Bir instansiyaga ikki yo‘l

To‘g‘ridan-to‘g‘ri yo‘l sizning tarmog‘ingizdan loyihaning VPCsigа private-services-access yo‘nalishidan foydalanadi. Mijozingiz instansiyaning xususiy manzili bilan PostgreSQL tilida gaplashadi va ulanish marshrutlash, firewall qoidalari va ma’lumotlar bazasi hisob ma’lumotlariga bog‘liq holda yashaydi yoki o‘ladi.

Proxy yo‘li xuddi shu yo‘nalishdan foydalanadi, lekin mahalliy jarayon qo‘shadi. Proxy ilovangizning default credentials bilan Google APIga autentifikatsiya qiladi, konnektor orqali instansiyaga ulanish ochadi va mijozingiz PostgreSQL deb qabul qiladigan loopback portini taqdim etadi. Ikki sakrash uchga aylanadi va o‘rtadagisi IAM avtorizatsiyasini olib yuradi. VPN yo‘nalishi baribir sizning xizmat ko‘rsatishingizda qoladi va proxy uni hech qachon bu tekshiruvning o‘rnini bosuvchi deb hisoblamaydi.

Har bir yo‘l aslida nimaga ruxsat beradi

Eng muhim farq — har bir variant sizning nomingizdan nimaga ruxsat bera olishi:

QuestionDirect private IPAuth Proxy
Who proves identity to the networkYour client, through the VPN and a database loginThe proxy, through IAM to Google's API
IAM role needed for the connectorNoneCloud SQL Client or equivalent
Database user authenticationAlways requiredStill required unless IAM database authentication is enabled
Shape of the local legClient to instanceClient to loopback, proxy to instance

Proxining IAM tekshiruvi va ma’lumotlar bazasiga kirish ikki alohida darvoza va biridan o‘tish ikkinchisini ochmaydi. Proxini yoqib, ilova hisobi endi kerak emas deb o‘ylagan jamoa tarmoqqa aloqasi bo‘lmagan parol xatolariga yarim kun sarflaydi.

Portlar va yo‘nalishlar, yonma-yon

Proxy API uchun chiquvchi TCP 443 va instansiya ulanishi uchun TCP 3307 talab qiladi, ikkisi ham Googlening Auth Proxy sharhida tasvirlangan. Sizning VPN yo‘nalishingiz ikkinchisini qoplaydi; birinchisi odatda odatiy yo‘l bilan chiqadi.

To‘g‘ridan-to‘g‘ri ulanish instansiyaning PostgreSQL porti xususiy yo‘nalish orqali yetib boriladigan bo‘lishini talab qiladi, bu butunlay boshqa firewall suhbati. Agar tarmoq jamoangiz mijoz subnetlaridan faqat 443 chiquvchisiga ruxsat bersa, proxy qoida o‘zgartirmasdan mos keladi, to‘g‘ridan-to‘g‘ri yo‘l esa mos kelmaydi. Aynan shu bitta fakt har qanday arxitektura afzalligidan ko‘ra ko‘proq tanlovni hal qiladi.

Ikkala yo‘l ham instansiyada ommaviy manzil bo‘lishini talab qilmaydi va hech biri uni qo‘shishni oqlamaydi.

Proxy yordam bermaydigan joy

Proxy yo‘qolgan yo‘nalishni tuzatmaydi. Agar private-services-access yo‘nalishi bo‘lmasa yoki VPN uni olib o‘tmasa, konnektor muvaffaqiyatsiz bo‘ladi, mahalliy tinglovchi esa hanuz o‘sha yerda o‘tirib tinglaydi — chalkashtiradigan qismi ham shu.

U ilovangiz va proxy o‘rtasidagi qismni ham himoya qilmaydi. Bitta noutbukda bu qism loopback va hammasi joyida. Agar hamkasbingiz yetib borishi uchun tinglovchini wildcard manzilga bog‘lasangiz, siz autentifikatsiyasiz ma’lumotlar bazasi darvozasini qurib, uni qulaylik deb atagansiz. Uni loopbackda saqlang va hamkasbingiz o‘z hisob ma’lumotlarini o‘zi olsin.

Va u Private Service Connect bilan private services accessni bir-birining o‘rnini bosadigan qilib qo‘ymaydi. PSC instansiyasiga o‘z DNS tartibi va --private-ip shakli o‘rniga --psc chaqiruvi kerak.

Tanlash, so‘ngra baribir tekshirish

Yo‘lda IAM, qisqa muddatli hisob ma’lumotlari va kiruvchi firewallda o‘zgarishsiz ishlashni istasangiz, proxini tanlang.

Qo‘llab-quvvatlanadigan mijozda allaqachon kuchli ma’lumotlar bazasi hisob ma’lumotlari bo‘lsa va tarmoq jamoasi portni ochishga tayyor bo‘lsa, to‘g‘ridan-to‘g‘ri yo‘nalishni tanlang. Baribir muvaffaqiyatli ulanish bilan emas, haqiqiy so‘rov bilan tekshiring: ulanib, ma’lum jadvalga bitta o‘qish ishlating va server sizning sessiyangiz haqida nima ko‘rishini ko‘ring.

VPN qayta ulangandan so‘ng muddati o‘tgan hisob ma’lumotlarini, yo‘qolgan xususiy yo‘nalishni va ma’lumotlar bazasiga kirishning rad etilishini uch xil nosozlik deb biling. Ulardan faqat bittasi tarmoq muammosi va faqat bittasi hech qachon firewall qoidasini o‘zgartirishga olib borishi kerak.

O'xshash maqolalar