Cloud SQL Auth Proxy در برابر مسیر مستقیم VPN به پایگاه داده
Auth Proxy و مسیر مستقیم VPN دو نیمه متفاوت از یک مسئله را حل می‌کنند. ابتدا مجوزدهی کانکتور، پورت‌ها و ورود به پایگاه داده را مقایسه کنید.
دو راه معقول برای رسیدن به یک نمونه خصوصی Cloud SQL از یک لپ‌تاپ متصل به VPN وجود دارد. یکی اتصال مستقیم به نشانی خصوصی نمونه از مسیری است که از قبل دارید. دیگری Cloud SQL Auth Proxy است که روی loopback گوش می‌دهد و خودش اتصال به Cloud SQL را باز می‌کند. این دو کمتر محصول رقیب‌اند و بیشتر دو پاسخ متفاوت به این پرسش که اعتبارنامه دست کیست و مسیر دست کیست. انتخاب بد معمولاً به‌صورت خطای مجوزدهی ظاهر می‌شود که مثل خطای شبکه خوانده می‌شود.
این مقایسه‌ای است که جلوی یک تیم می‌گذارم، و پس از آن بررسی‌هایی که واقعاً تصمیم را می‌گیرند.
دو مسیر به یک نمونه
مسیر مستقیم از مسیر private-services-access از شبکه شما به VPC پروژه استفاده می‌کند. کلاینت شما با PostgreSQL با نشانی خصوصی نمونه حرف می‌زند، و اتصال بر مسیریابی، قواعد firewall و اعتبارنامه‌های پایگاه داده زنده می‌ماند یا می‌میرد.
مسیر پروکسی همان مسیر را به کار می‌برد اما یک فرایند محلی اضافه می‌کند. پروکسی با application default credentials شما در Google API احراز هویت می‌کند، از طریق connector اتصالی به نمونه باز می‌کند و پورتی روی loopback ارائه می‌دهد که کلاینت شما آن را PostgreSQL می‌پندارد. دو پرش به سه تبدیل می‌شود و پرش میانی مجوزدهی IAM را حمل می‌کند. مسیر VPN هنوز چیزی است که باید خودتان نگهداری کنید و پروکسی هرگز آن را جایگزین این بررسی نمی‌داند.
هر مسیر واقعاً چه چیزی را مجاز می‌کند
مهم‌ترین تفاوت این است که هر گزینه چه چیزی را به‌جای شما مجاز می‌کند:
| 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 |
بررسی IAM در پروکسی و ورود به پایگاه داده دو دروازه جدا هستند و گذشتن از یکی دیگری را باز نمی‌کند. تیمی که پروکسی را فعال می‌کند و فرض می‌کند حساب برنامه دیگر لازم نیست، یک بعدازظهر را صرف خطاهای گذرواژه می‌کند که هیچ ربطی به شبکه ندارند.
پورت‌ها و مسیرها، کنار هم
پروکسی برای API به TCP 443 خروجی و برای اتصال نمونه به TCP 3307 نیاز دارد که هر دو در مروری بر Auth Proxy توضیح داده شده‌اند. مسیر VPN شما دومی را پوشش می‌دهد؛ اولی معمولاً از راه معمول خارج می‌شود.
اتصال مستقیم نیاز دارد که پورت PostgreSQL نمونه از مسیر خصوصی قابل دسترسی باشد، که گفت‌وگویی کاملاً متفاوت درباره firewall است. اگر تیم شبکه شما فقط 443 خروجی از زیرشبکه‌های کلاینت را مجاز بداند، پروکسی بدون تغییر قاعده جا می‌شود و مسیر مستقیم جا نمی‌شود. همین یک واقعیت بیشتر از هر ترجیح معماری انتخاب را تعیین می‌کند.
هیچ‌کدام از دو مسیر نیاز ندارد که نمونه نشانی عمومی داشته باشد و هیچ‌کدام افزودن یکی را توجیه نمی‌کند.
جایی که پروکسی کمک نمی‌کند
پروکسی مسیر گم‌شده را درست نمی‌کند. اگر مسیر private-services-access وجود نداشته باشد، یا VPN آن را حمل نکند، connector شکست می‌خورد در حالی که شنونده محلی همچنان آنجا نشسته و گوش می‌دهد، و بخش گیج‌کننده همین است.
همچنین بخش میان برنامه و پروکسی را محافظت نمی‌کند. روی یک لپ‌تاپ آن بخش loopback است و مشکلی نیست. اگر شنونده را به نشانی wildcard ببندید تا همکاری به آن برسد، یک دروازه پایگاه داده بدون احراز هویت ساخته‌اید و آن را راحتی نامیده‌اید. آن را روی loopback نگه دارید و بگذارید همکار اعتبارنامه خودش را بگیرد.
و Private Service Connect و private services access را قابل جانشینی نمی‌کند. یک نمونه PSC به ترتیب DNS خودش و به فراخوانی --psc به‌جای شکل --private-ip نیاز دارد.
انتخاب، و سپس تأیید در هر دو حالت
وقتی IAM در مسیر، اعتبارنامه‌های کوتاه‌مدت و بدون تغییر firewall ورودی می‌خواهید، پروکسی را انتخاب کنید.
وقتی یک کلاینت پشتیبانی‌شده از قبل اعتبارنامه‌های قوی پایگاه داده دارد و تیم شبکه از باز کردن پورت راحت است، مسیر مستقیم را انتخاب کنید. در هر حال با یک کوئری واقعی تأیید کنید نه با اتصال موفق: متصل شوید، یک خواندن روی جدولی شناخته‌شده اجرا کنید و ببینید سرور درباره نشست شما چه می‌بیند.
پس از اتصال دوباره VPN، اعتبارنامه منقضی، مسیر خصوصی گم‌شده و رد ورود به پایگاه داده را سه شکست متفاوت بدانید. فقط یکی از آن‌ها مسئله شبکه است و فقط یکی باید هرگز به تغییر قاعده firewall منجر شود.