عنوان IP الخاص لـ Cloud SQL عبر VPN: المسار الذي لا يصدّره أحد

كثير من الفرق تعتقد أن عنوان IP الخاص لـ Cloud SQL يعمل فقط من داخل VPC، ويستمر هذا الاعتقاد لأن العطل يبدو كمشكلة في قاعدة البيانات. توثّق Google الوصول من الشبكات المتصلة عبر Cloud VPN أو Cloud Interconnect. ما تحتاجه تلك الشبكات ليس ميزة خاصة في قاعدة البيانات، بل تبادلا توجيه يسهل تركه نصف مُهيّأ. يرتفع النفق، وتستجيب مثيلات الحوسبة، ثم تنتهي مهلة اتصال قاعدة البيانات، وهي بالضبط التركيبة التي ترسل الناس إلى وحدة التحكم الخطأ.

خرافة: عنوان IP الخاص يعني خاصًا بـ VPC

الوصول إلى الخدمات الخاصة هو اقتران VPC بين شبكتك وشبكة منتِج تملكها Google. يقع النطاق المخصص للخدمة على جانب المنتِج، وعنوان المثيل داخله. هذا الاقتران هو سبب إمكانية وجود قاعدة بيانات في مشروعك على عنوان يوجّه إليه VPC الخاص بك دون أن يحتويه أي subnet صريح لديك.

ولأنه اقتران، فهو يحمل سلوك الاقتران أيضًا، بما في ذلك الجزء الذي لا تعبر فيه المسارات المخصصة تلقائيًا.

خرافة: النفق العامل يحمل معه مسار قاعدة البيانات

يجب أن ينجو نطاقان من الرحلة. الأول هو بادئة العميل: يجب أن تعرف شبكتك المحلية لدى Cloud Router ببادئات محددة، لأن المسار الافتراضي لا يستطيع توفير الاستيراد الذي تحتاجه شبكة المنتِج لمسار العودة. والثاني هو نطاق الخدمة المخصص، الذي يجب أن يتعلمه الجانب الخارجي حتى تجد حزمه المتجهة إلى قاعدة البيانات مكانًا تذهب إليه. هذان مساران مختلفان يُصانان عند حدود مختلفة، وإصلاح أحدهما يترك الآخر معطلًا.

على جانب Google، يعني ذلك تمكين Export custom routes على اتصالات الاقتران المعنية وإضافة نطاق الخدمة المخصص إلى المسارات المعلنة لـ Cloud Router من أجل النفق.

أبقِ الإعلانات الموجودة بالفعل. إضافة نطاق الخدمة يجب ألا تزيل مسارات VPC التي تحملها جلسة BGP نفسها لحركة أخرى، ومجموعة إعلانات تُستبدل بالكامل هي انقطاع ثانٍ مختبئ خلف الأول. تحقق أيضًا من المسارات الفعلية على الجهاز الخارجي، لأن القدرة على الوصول إلى بوابة VPN أو إلى subnet آخر لا تثبت سوى النقل.

خرافة: Cloud SQL Auth Proxy يحل مشكلة الشبكة

The Auth Proxy يوفر مصادقة مدعومة ونقلًا مشفرًا بين تطبيقك والمثيل. لكنه لا ينشئ مسارًا. الوكيل الذي يبدأ على مضيف بلا مسار إلى الشبكة الخاصة سيفشل تمامًا كما يفشل الاتصال المباشر، وستكون سجلاته أقل إفادة عن السبب. نقل الوكيل إلى مضيف لديه اتصال يغيّر أي جزء من المسار يجب أن يعمل، وهذا قرار تصميمي حقيقي وليس حلًا بديلًا.

ما لا يفعله هو تمكين حاسوب محمول غير متصل من الوصول إلى مثيل خاص فقط.

خرافة: Private Service Connect يتبع القواعد نفسها

يستخدم Private Service Connect نقطة نهاية في subnet الخاص بك وترتيب DNS تتحكم به، لذا فإن المسار إليه مسار عادي إلى عنوان تملكه. لا تنطبق إعدادات تصدير الاقتران على ذلك التصميم، ونقل تغييرات الاقتران إلى نشر PSC يضيف مخاطرة دون إضافة إمكانية وصول.

كلاهما يعطيك عنوانًا خاصًا؛ والتشابه ينتهي عند هذا الحد.

اختبر المسار بالترتيب الصحيح

من العميل الخارجي، اختبر نقطة نهاية TCP لقاعدة البيانات أولًا. اكتمال مصافحة TCP يعني أن التوجيه والجدار الناري والمستمع كلها في مكانها، والاختبار التالي هو عملية مصادق عليها ومسموحة. رفض المصادقة عندئذ خبر جيد في الواقع، لأنه يثبت أن مستمع قاعدة البيانات قد أجاب. أما انتهاء مهلة ICMP فلا يقول شيئًا تقريبًا عن الوصول إلى قاعدة البيانات، لأن كثيرًا من المسارات تُسقطه وهي تمرر TCP بسهولة.

إذا كانت نطاقات عملائك خارج RFC 1918، فراجع متطلبات تصدير المسارات وتفويض الشبكة الإضافية قبل أن تستنتج أن التصميم غير مدعوم.

سجّل أربعة عناصر مع الاتصال: البادئة الخارجية، ونطاق الخدمة المخصص، واتصالات الاقتران المعنية، والموجّه الذي يقوم بالإعلان. هذه الأربعة تشرح المسار الخاص كله، وتحل محل الأسطورة القائلة إن Cloud SQL إما يحتاج دائمًا إلى وكيل أو لا يمكن الوصول إليه عبر VPN إطلاقًا.