GCP Cloud VPN: تحقّق من البوابة والنفق والجدار الناري بالترتيب

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

أربعة قرارات تفصل بين تلك الأيقونة الخضراء والردّ، وهي تفشل بترتيب متوقّع. ابدأ بها من الأرخص.

ثلاثة كائنات، وواحد فقط منها يقوم بالتشفير

بوابة VPN تملك العنوان الخارجي الذي يشفّر إليه نظيرك. في وحدة التحكّم لا تنشئها يدويًا أبدًا: اختر عنوانًا أو احجزه داخل نموذج الاتصال فتظهر البوابة معه. بوابة HA تأخذ عنوانين على واجهتين، وهذا ما يهمّ عند فحص الحصص لاحقًا.

النفق هو الاقتران بين تلك البوابة والنظير. وهو يحمل السرّ المشترك ومحدِّدات حركة المرور التي يتعهّد بحمايتها. تلك المحدِّدات هي حيث تبدأ معظم حالات الفشل الصامت. النفق الذي يغطّي محدِّده المحلي 10.0.0.0/24 لن يوصل 10.0.1.0/24، مهما بدت الحالة سليمة.

يحتفظ الطرف البعيد بقائمته الخاصة، وتُسمّى عادةً نطاق تشفير، وتقارنها العتاديات الطرفية بقائمتك. ولا يتفاوض أي طرف على محدِّد لم يُعطَه إياه.

نوع التوجيه يحدّد ما يصل إلى جدول المسارات

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

النفق الديناميكي الذي تجاوره مسارات ثابتة مكتوبة يدويًا ينتج جدول مسارات يفرغ كلما اهتزّت جلسة BGP.

الديناميكي هو الشكل الوحيد الذي يسمح بتغيّر البادئات المحمية دون إعادة بناء النفق، وهو يجرّ Cloud Router إلى مجموعة الكائنات التي عليك التحقّق منها. تبقى المحدِّدات الثابتة قابلة للعمل عندما يكون النظير جدارًا ناريًا عتاديًا لا يستطيع التحدّث بـ BGP. عندئذٍ يحتاج الطرفان إلى النطاقات نفسها، ويجب أن يفوز الإدخال الأكثر تحديدًا في كليهما. الزوج الذي يختلف بشبكة فرعية واحدة يؤسّس ثم يحمل نصف حركتك.

الرفض الضمني يقف خلف النفق

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

اقرأ سجل رفض الجدار الناري بدلًا من ذلك عندما يكون النفق قائمًا وينتهي وقت الفحص، ثم اضبط قاعدة على نطاق المصدر والمنافذ التي تحتاجها:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

عمل اتجاه واحد فقط دليل على الجدار الناري

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

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

المحدِّدات والحصص ثم الفحوص الأربعة

أنفاق أُنشئت من وحدة التحكّم تعيد أحيانًا محدِّد حركة مرور بعيد فارغ من gcloud compute vpn-tunnels describe بينما تحمل المسارات المولّدة الحركة بشكل صحيح. قارن ما تسجّله الواجهة البرمجية بالنطاقات التي تحميها فعليًا قبل أن تقرّر أن النفق خاطئ. إنشاؤه عبر API أو SDK يبقي المحدِّد صريحًا.

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

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