Cloud SQL Auth Proxy مقابل مسار VPN مباشر إلى قاعدة البيانات
يحل Auth Proxy ومسار VPN المباشر نصفين مختلفين من المشكلة نفسها. قارن أولًا تفويض الموصل والمنافذ وتسجيل الدخول إلى قاعدة البيانات.
هناك طريقتان معقولتان للوصول إلى نسخة Cloud SQL خاصة من حاسوب محمول على الـ VPN. الأولى اتصال مباشر بالعنوان الخاص للنسخة عبر المسار الذي لديك بالفعل. والثانية هي Cloud SQL Auth Proxy، الذي يستمع على loopback ويفتح الاتصال بـ Cloud SQL نفسه. هما ليسا منتجين متنافسين بقدر ما هما إجابتان مختلفتان عن سؤال من يحمل بيانات الاعتماد ومن يحمل المسار. وغالبًا ما يظهر الاختيار الخاطئ كخطأ في التفويض يُقرأ كخطأ في الشبكة.
هذه هي المقارنة التي أضعها أمام الفريق، تليها الفحوصات التي تحسم الأمر فعليًا.
مساران إلى النسخة نفسها
يستخدم المسار المباشر مسار الوصول إلى الخدمات الخاصة من شبكتك إلى VPC الخاص بالمشروع. يتحدث عميلك مع العنوان الخاص للنسخة بلغة PostgreSQL، ويعيش الاتصال أو يموت على التوجيه وقواعد الجدار الناري وبيانات اعتماد قاعدة البيانات.
يستخدم مسار الوكيل المسار نفسه لكنه يضيف عملية محلية. يصادق الوكيل على واجهة Google API ببيانات الاعتماد الافتراضية لتطبيقك، ويفتح اتصالًا بالنسخة عبر الموصل، ويكشف منفذ 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 الذي يجريه الوكيل وتسجيل الدخول إلى قاعدة البيانات بوابتان منفصلتان، وعبور إحداهما لا يفتح الأخرى. والفريق الذي يمكّن الوكيل ويفترض أن حساب التطبيق لم يعد ضروريًا سيقضي عصرًا كاملًا في إصلاح أعطال كلمات المرور التي لا علاقة لها بالشبكات.
المنافذ والمسارات جنبًا إلى جنب
يحتاج الوكيل إلى TCP 443 صادر من أجل API وTCP 3307 لاتصال النسخة، وكلاهما موصوف في نظرة عامة على Auth Proxy. ويغطي مسار VPN لديك الثاني؛ أما الأول فيخرج عادة عبر المسار العادي.
يحتاج الاتصال المباشر إلى أن يكون منفذ PostgreSQL للنسخة قابلًا للوصول عبر المسار الخاص، وهي محادثة مختلفة تمامًا مع الجدار الناري. وإذا كانت شبكتك تسمح فقط بـ 443 صادر من شبكات العملاء الفرعية، فإن الوكيل يناسب دون تغيير أي قاعدة والمسار المباشر لا يناسب. وهذه الحقيقة الواحدة تحسم الاختيار أكثر من أي تفضيل معماري.
لا يتطلب أي من المسارين أن يكون للنسخة عنوان عام، ولا يبرر أي منهما إضافة واحد.
حيث لا يساعد الوكيل
الوكيل لا يصلح مسارًا مفقودًا. إذا كان مسار الوصول إلى الخدمات الخاصة غائبًا، أو لم يكن الـ VPN يحمله، يفشل الموصل بينما يظل المستمع المحلي جالسًا هناك يستمع، وهذا هو الجزء المربك.
كما أنه لا يحمي الوصلة بين تطبيقك والوكيل. على حاسوب محمول واحد تكون تلك الوصلة loopback وهذا جيد. أما إذا ربطت المستمع بعنوان wildcard ليتمكن زميل من الوصول إليه، فقد بنيت بوابة قاعدة بيانات بلا مصادقة وسميتها راحة. أبقِه على loopback ودع الزميل يحصل على بيانات اعتماده الخاصة.
ولا يجعل Private Service Connect وprivate services access قابلين للتبادل. فنسخة PSC تحتاج إلى ترتيب DNS خاص بها وإلى استدعاء --psc بدلًا من صيغة --private-ip.
الاختيار ثم التحقق في كلتا الحالتين
اختر الوكيل حين تريد IAM في المسار وبيانات اعتماد قصيرة العمر ودون تغيير في الجدار الناري الوارد.
اختر المسار المباشر حين يمتلك عميل مدعوم بالفعل بيانات اعتماد قوية لقاعدة البيانات وكان فريق الشبكة مرتاحًا لفتح المنفذ. وفي الحالتين تحقق باستعلام حقيقي لا باتصال ناجح: اتصل، ونفّذ قراءة واحدة على جدول معروف، وتحقق مما يراه الخادم بشأن جلستك.
بعد إعادة اتصال VPN، اعتبر بيانات الاعتماد المنتهية والمسار الخاص المفقود ورفض تسجيل الدخول إلى قاعدة البيانات ثلاثة أعطال مختلفة. واحد فقط منها مشكلة شبكة، وواحد فقط ينبغي أن يؤدي إلى تغيير قاعدة جدار ناري.