آی‌پی خصوصی Cloud SQL روی VPN: مسیری که هیچ‌کس صادر نمی‌کند
آی‌پی خصوصی Cloud SQL از یک شبکه متصل به VPN کار می‌کند، اما تنها زمانی که هم پیشوند مشتری و هم بازه سرویس از دو مرز مسیریابی عبور کنند.
بسیاری از تیم‌ها باور دارند که آی‌پی خصوصی Cloud SQL فقط از داخل VPC کار می‌کند، و این باور می‌ماند چون خطا شبیه یک مشکل پایگاه داده به نظر می‌رسد. گوگل دسترسی از شبکه‌هایی را که با Cloud VPN یا Cloud Interconnect وصل می‌شوند مستند کرده است. آن شبکه‌ها به یک قابلیت ویژه پایگاه داده نیاز ندارند، بلکه به دو تبادل مسیر نیاز دارند که نیمه‌کاره رها کردنشان آسان است. تونل بالا می‌آید، نمونه‌های محاسباتی پاسخ می‌دهند و اتصال پایگاه داده زمان‌بندی می‌شود — دقیقاً همان ترکیبی که مردم را به کنسول اشتباه می‌فرستد.
افسانه: آی‌پی خصوصی یعنی خصوصی نسبت به VPC
دسترسی به سرویس‌های خصوصی یک همتابینی VPC میان شبکه شما و یک شبکه تولیدکننده متعلق به گوگل است. بازه تخصیص‌یافته برای سرویس در سمت تولیدکننده قرار دارد و نشانی نمونه درون آن است. همین همتابینی دلیل آن است که یک پایگاه داده در پروژه شما می‌تواند روی نشانی بنشیند که VPC شما به آن مسیریابی می‌کند، بدون آنکه هیچ زیرشبکه صریحی از شما آن را در بر بگیرد.
چون همتابینی است، رفتار همتابینی هم دارد، از جمله بخشی که در آن مسیرهای سفارشی به‌طور خودکار عبور نمی‌کنند.
افسانه: تونل سالم مسیر پایگاه داده را با خود می‌برد
دو بازه باید از این سفر جان سالم به در ببرند. اولی پیشوند مشتری است: شبکه داخلی شما باید با پیشوندهای مشخص برای Cloud Router شناخته شود، چون یک مسیر پیش‌فرض نمی‌تواند وارداتی را فراهم کند که شبکه تولیدکننده برای مسیر برگشت لازم دارد. دومی بازه تخصیص‌یافته سرویس است که طرف بیرونی باید آن را یاد بگیرد تا بسته‌هایش برای پایگاه داده جایی برای رفتن داشته باشند. این‌ها مسیرهای متفاوتی هستند که در مرزهای متفاوت نگهداری می‌شوند، و درست کردن یکی دیگری را خراب رها می‌کند.
در سمت گوگل این یعنی فعال کردن Export custom routes روی اتصال‌های همتابینی مربوطه و افزودن بازه تخصیص‌یافته سرویس به مسیرهای اعلام‌شده Cloud Router برای تونل.
اعلان‌هایی را که از قبل هست نگه دارید. افزودن بازه سرویس نباید مسیرهای VPC را که همان نشست BGP برای ترافیک دیگر حمل می‌کند حذف کند، و مجموعه اعلانی که یکجا جایگزین شود یک قطعی دوم است که پشت اولی پنهان شده. مسیرهای مؤثر روی دستگاه بیرونی را هم بررسی کنید، چون رسیدن به دروازه VPN یا زیرشبکه‌ای دیگر فقط انتقال را ثابت می‌کند.
افسانه: Cloud SQL Auth Proxy شبکه را حل می‌کند
The Auth Proxy احراز هویت پشتیبانی‌شده و انتقال رمزنگاری‌شده میان برنامه شما و نمونه را فراهم می‌کند. اما مسیری نمی‌سازد. پراکسی‌ای که روی میزبان بدون مسیر به شبکه خصوصی اجرا شود دقیقاً مثل یک اتصال مستقیم شکست می‌خورد و گزارش‌هایش درباره دلیل کمتر کمک‌کننده خواهند بود. جابه‌جا کردن پراکسی به میزبانی که اتصال دارد تغییر می‌دهد کدام بخش مسیر باید کار کند، و این یک تصمیم طراحی واقعی است نه یک راه‌حل میان‌بر.
کاری که نمی‌کند این است که به یک لپ‌تاپ قطع‌شده اجازه دهد به نمونه‌ای که فقط خصوصی است برسد.
افسانه: Private Service Connect از همان قواعد پیروی می‌کند
Private Service Connect از یک نقطه پایانی در زیرشبکه خودتان و ترتیبی از DNS که کنترل می‌کنید استفاده می‌کند، پس مسیر رسیدن به آن یک مسیر معمولی به نشانی است که مالک آن هستید. تنظیمات صدور همتابینی به آن طراحی اعمال نمی‌شود، و کپی کردن تغییرات همتابینی در یک استقرار PSC خطر را بدون افزودن دسترس‌پذیری اضافه می‌کند.
هر دو به شما نشانی خصوصی می‌دهند؛ شباهت همان‌جا تمام می‌شود.
مسیر را به ترتیب درست آزمایش کنید
از مشتری بیرونی، ابتدا نقطه پایانی TCP پایگاه داده را آزمایش کنید. دست‌دهی کامل TCP یعنی مسیریابی، فایروال و شنونده همه سر جای خود هستند، و آزمایش بعدی یک عملیات احراز هویت‌شده مجاز است. رد شدن احراز هویت در آن لحظه در واقع خبر خوبی است، چون ثابت می‌کند شنونده پایگاه داده پاسخ داده است. یک وقفه ICMP تقریباً هیچ چیزی درباره دسترسی به پایگاه داده نمی‌گوید، چون بسیاری از مسیرها آن را دور می‌ریزند در حالی که TCP را بی‌دردسر عبور می‌دهند.
اگر بازه‌های مشتری شما بیرون از RFC 1918 است، پیش از آنکه نتیجه بگیرید طراحی پشتیبانی نمی‌شود، الزامات اضافی صدور مسیر و مجوزدهی شبکه را بررسی کنید.
چهار شیء را همراه اتصال ثبت کنید: پیشوند بیرونی، بازه تخصیص‌یافته سرویس، اتصال‌های همتابینی درگیر و روتری که اعلان می‌دهد. این چهار مورد تمام مسیر خصوصی را توضیح می‌دهند و آن افسانه را جایگزین می‌کنند که Cloud SQL یا همیشه به پراکسی نیاز دارد یا اصلاً از طریق VPN در دسترس نیست.