يمكن لـ App Engine الوصول إلى قاعدة بيانات VPN لديك: ما يجب أن يتطابق

الادعاء بأن App Engine Standard لا يستطيع الوصول إلى قاعدة بيانات خاصة عبر Cloud VPN هو بقايا من جيل أقدم من المنصة. لا تحصل نسخ Standard على عنوان أصلي في VPC كما تفعل بعض بيئات التشغيل الأخرى، لكنها تستطيع إرسال حركة الخروج عبر موصل Serverless VPC Access يوجد داخل شبكتك. وبمجرد وجود هذا المسار، يرى Cloud VPN وجدار الحماية البعيد حركة الموصل كمصدر كأي مصدر آخر. وما يفشل نادراً هو القدرة نفسها، بل أحد ثلاثة إعدادات لم تُضبط لتتوافق.

من أين جاء الجواب القديم

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

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

اختر مسار الخروج أولاً

الموصل المرتبط بالخدمة هو ما يضع حركتها داخل VPC. توثيق الموصل يسرد المتطلب الإقليمي وإعدادات الخروج؛ ويجب أن يوجد الموصل في منطقة الخدمة وأن تكون هوية النشر قادرة على استخدامه.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only يرسل الوجهات الخاصة إلى VPC ويترك كل شيء آخر على مسار الإنترنت العادي، وهو ما يحتاجه اتصال قاعدة البيانات عادةً. أما all-traffic فيدفع حركة الخروج عبر VPC على نطاق واسع، فترث استدعاءات الإنترنت العادية أيضاً وضع NAT وجدار الحماية في VPC.

تعديل الملف محلياً لا يغيّر شيئاً حتى تنشر. النسخة العاملة تحتفظ بالإعداد الذي أُنشئت به.

عنوان المصدر هو الموصل، وليس حاسوبك المحمول

هنا يذهب معظم وقت التصحيح. تحتاج بوابة VPN البعيدة وجدار حماية قاعدة البيانات إلى قبول النطاق المخصص للموصل داخل VPC، لا عنوان مكتبك ولا عنوان الخروج العام للخدمة. ابحث عن ذلك النطاق في وحدة التحكم قبل كتابة قاعدة واحدة.

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

النفق الذي يقبل شبكة فرعية VM فقط سيسقط حزم الموصل دون رسالة خطأ مفيدة، ولهذا تبدو مهلة قاعدة البيانات كمشكلة بيانات اعتماد.

يسلك DNS مساراً مختلفاً

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

إذا حُلّ الاسم إلى عنوان عام من داخل VPC، فأنت على وشك تصحيح جدار الحماية الخطأ.

URL Fetch لا يستخدم الموصل

إعداد الخروج يغطي مقابس الخروج العادية لبيئة التشغيل، وخدمة URL Fetch القديمة ليست جزءاً من ذلك المسار. الطلب الصادر عبر urlfetch يتجاهل الموصل مهما قال الإعداد. عندما يقع الاستدعاء الفاشل داخل مكتبة أقدم ما زالت تستخدم URL Fetch، فالإصلاح هو نقل ذلك الاستدعاء إلى عميل HTTP القياسي.

بالنسبة إلى برنامج تشغيل قاعدة بيانات، نادراً ما تكون هذه هي المشكلة، لكنها السبب الكلاسيكي لنجاح نقطة نهاية وفشل أخرى من الخدمة نفسها.

تحقق باستعلام واحد ضيق

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

استعلام ناجح من VM داخل VPC يثبت وجود المسار. لكنه لا يثبت أن الخدمة اختارته.