Cloud Run إلى VPN المحلية: إعداد خروج VPC المباشر

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

اربط الإصدار قبل تشخيص النفق

يدعم Cloud Run خروج VPC المباشر، وهو يضع مرور الخدمة على شبكة فرعية داخل شبكة VPC دون موصّل Serverless VPC Access. بالنسبة لخدمة قائمة يبدو التحديث هكذا:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

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

اختر نمط الخروج الذي يطابق الوجهة

private-ranges-only يرسل الوجهات التي يصنفها كخاصة عبر شبكة VPC. وهو لا يعني «أي شيء يمكن الوصول إليه عبر VPN»، وتظهر هذه الفجوة عندما تكون الخدمة المحلية في نطاق لا يصنفه الإعداد بهذه الطريقة. إذا لم تكن الوجهة مغطاة، فإن all-traffic هو النمط الآخر الموثّق، وهو يرسل كل شيء عبر شبكة VPC، بما في ذلك تبعيات الخدمة العامة. اختر بوعي واكتب النتيجة في سجل التغيير.

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

وجّه مصدر Cloud Run، لا مصدر الجهاز الظاهري

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

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

ثلاثة شروط يجب أن تتحقق جميعها

المسار العامل يحتاج إلى كل ما يلي، وكل واحد منها يفشل بطريقته الخاصة:

• مسار في شبكة VPC نحو البادئة المحلية عبر اتصال Cloud VPN المقصود.
• مسار عكسي على الجانب المحلي للشبكة الفرعية لـ Cloud Run.
• نطاق حماية الجدار الناري وIPsec يسمح بالمصدر والوجهة والمنفذ.

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

لا تضع عنوان Cloud Run مؤقتًا واحدًا في قائمة السماح. استخدم نطاق الشبكة الفرعية وتصميم تفويض يناسب التطبيق.

اختبر الإصدار الذي خدم الطلب

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

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

التراجع وما لا يفعله هذا

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

يغطي هذا التصميم الاتصالات التي يبدأها Cloud Run وردودها. وهو لا يمنح الشبكة المحلية مقبسًا قابلًا للعنونة داخل الخدمة، لأن التعرية الواردة قرار دخول.