Cloud SQL Auth Proxy və verilənlər bazasına birbaşa VPN marşrutu
Auth Proxy və birbaşa VPN marşrutu eyni problemin iki fərqli yarısını həll edir. Əvvəlcə connector avtorizasiyasını, portları və verilənlər bazasına girişi müqayisə edin.
VPN-də olan bir noutbukdan xüsusi Cloud SQL instansiyasına çatmağın iki ağlabatan yolu var. Biri artıq malik olduğunuz marşrut üzərindən instansiyanın xüsusi ünvanına birbaşa qoşulmadır. Digəri isə loopback üzərində dinləyən və Cloud SQL-ə özü qoşulma açan Cloud SQL Auth Proxy-dir. Onlar rəqib məhsullardan çox, etimadnaməni kimin saxladığı və marşrutu kimin saxladığı sualına verilən iki fərqli cavabdır. Səhv seçim adətən şəbəkə xətası kimi oxunan avtorizasiya xətası kimi üzə çıxır.
Budur komandanın qarşısına qoyacağım müqayisə, ardınca isə bunu həqiqətən həll edən yoxlamalar.
Eyni instansiyaya iki yol
Birbaşa yol şəbəkənizdən layihənin VPC-sinə private-services-access marşrutundan istifadə edir. Klientiniz PostgreSQL dilində instansiyanın xüsusi ünvanı ilə danışır və bağlantı marşrutlaşdırma, firewall qaydaları və verilənlər bazası etimadnamələri üzərində yaşayır ya da ölür.
Proxy yolu eyni marşrutdan istifadə edir, lakin yerli bir proses əlavə edir. Proxy tətbiqinizin default etimadnamələri ilə Google API-yə autentifikasiya olur, connector vasitəsilə instansiyaya bağlantı açır və klientinizin PostgreSQL kimi qəbul etdiyi bir loopback portunu təqdim edir. İki sıçrayış üçə çevrilir və ortadakı IAM avtorizasiyasını daşıyır. VPN marşrutu yenə sizin saxlamalı olduğunuz şeydir və proxy heç vaxt onu bu yoxlamanın əvəzi saymır.
Hər yol əslində nəyə icazə verir
Ən çox əhəmiyyət kəsb edən fərq hər variantın sizin üçün nəyə icazə verə bilməsidir:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
Proxy-nin IAM yoxlaması və verilənlər bazasına giriş ayrı-ayrı qapılardır və birindən keçmək digərini açmır. Proxy-ni aktivləşdirib tətbiq hesabının artıq lazımsız olduğunu düşünən komanda şəbəkə ilə heç bir əlaqəsi olmayan parol uğursuzluqlarına günün yarısını sərf edəcək.
Portlar və marşrutlar yan-yana
Proxy API üçün çıxan TCP 443 və instansiya bağlantısı üçün TCP 3307 tələb edir; hər ikisi Google-un Auth Proxy icmalı. VPN marşrutunuz ikincisini əhatə edir; birincisi adətən adi yol ilə çıxır.
Birbaşa bağlantı instansiyanın PostgreSQL portunun xüsusi marşrut üzərindən əlçatan olmasını tələb edir ki, bu tamamilə başqa bir firewall söhbətidir. Şəbəkə komandanız klient subnetlərindən yalnız 443 çıxışına icazə verirsə, proxy heç bir qayda dəyişikliyi olmadan uyğun gəlir, birbaşa yol isə uyğun gəlmir. Bu tək fakt seçimi istənilən arxitektura üstünlüyündən daha tez-tez həll edir.
Heç bir yol instansiyanın ümumi ünvana sahib olmasını tələb etmir və heç biri belə bir ünvan əlavə etməyi əsaslandırmır.
Proxy-nin kömək etmədiyi yerlər
Proxy çatışmayan marşrutu düzəltmir. Əgər private-services-access marşrutu yoxdursa və ya VPN onu daşımırsa, connector uğursuz olur, halbuki yerli dinləyici hələ də orada oturub dinləyir — çaşdırıcı hissə də budur.
O, həmçinin tətbiqinizlə proxy arasındakı ayağı qorumur. Bir noutbukda bu ayaq loopback-dir və problem yoxdur. Dinləyicini həmkarınız çata bilsin deyə wildcard ünvana bağlasanız, autentifikasiyasız bir verilənlər bazası şlüzü qurmuş və ona rahatlıq demiş olursunuz. Onu loopback-də saxlayın və qoy həmkarınız öz etimadnaməsini əldə etsin.
Və o, Private Service Connect ilə private services access-i bir-birini əvəz edən etmir. PSC instansiyası öz DNS tənzimləməsini və --private-ip forması yerinə --psc çağırışını tələb edir.
Seçmək, sonra hər iki halda yoxlamaq
Yolda IAM, qısa ömürlü etimadnamələr və daxil olan firewall dəyişikliyi olmadan işləmək istəyirsinizsə, proxy-ni seçin.
Dəstəklənən klient artıq güclü verilənlər bazası etimadnamələrinə sahibdirsə və şəbəkə komandası portu açmağa hazırdırsa, birbaşa marşrutu seçin. Hər halda uğurlu bağlantı ilə deyil, real sorğu ilə yoxlayın: qoşulun, tanınan cədvələ qarşı bir oxuma işlədin və serverin sessiyanız üçün nə gördüyünü yoxlayın.
VPN yenidən qoşulduqdan sonra vaxtı keçmiş etimadnaməni, çatışmayan xüsusi marşrutu və verilənlər bazasına girişin rədd edilməsini üç fərqli nasazlıq kimi qəbul edin. Onlardan yalnız biri şəbəkə problemidir və yalnız biri heç vaxt firewall qaydasının dəyişdirilməsinə gətirməlidir.