GCP Classic VPN في Terraform: اجعل النفق قائمًا على المسار

الخطة تُطبَّق بسلاسة، والنفق يعمل، ولوحة التحكم تسميه قائمًا على السياسة. ولا يزال المرور لا يمر، والبحث عن مفتاح قائم على المسار في مورد Terraform لا يؤدي إلى شيء لأن هذا الحقل غير موجود. في Classic VPN، السلوك القائم على المسار ليس وضعًا تختاره. وهو ما تحصل عليه عندما يكون محدد المرور المحلي 0.0.0.0/0، ومحددات المرور البعيدة تسرد الشبكات التي تريدها فعلاً، ومسار يشير إلى النفق. ثلاثة أشياء، ويتبعها التصنيف.

الأسطورة: حقل وضع النفق

تصنيف لوحة التحكم يعكس ما تراه واجهة API في المحددات. لا شيء في المورد يقول قائم على المسار، لذا لا يوجد ما يُضبط على قيمة صحيحة.

البحث عن ذلك الحقل يستهلك الساعة الأولى من المشكلة، بينما قراءة قيم المحددات تستغرق الخمس دقائق الأخيرة.

ماذا يعني القائم على المسار هنا

توثّق Google أنفاق Classic VPN القائمة على المسار كأنفاق قائمة على السياسة يكون محددها المحلي 0.0.0.0/0. ولا تُسمّى سوى النطاقات البعيدة، ويُعامَل الجانب المحلي كأي عنوان. ولهذا فإن العلامة في إعدادك قيمة وليست وضعًا. اكتب المحددين صراحةً واقرأهما في مخرجات الخطة:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

بادئة النظير في ذلك المقتطف توضيحية؛ الشكل هو الجزء المهم.

المسار كائن منفصل

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

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

أنشئ المسار في الوحدة نفسها التي فيها النفق، حتى لا ينفصل الاثنان أثناء المراجعة.

اعكس المحددات على النظير

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

اطبع محددات الجانبين جنبًا إلى جنب أثناء مراجعة التغيير.

قسّم العنوان الثابت إلى تطبيقين

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

تطبيقان الآن أرخص من تغيير النظير في كل إصدار.

تحقق من التفاوض، لا من التصنيف

بعد التطبيق، تحقق من ثلاثة حقائق منفصلة: النفق يُبلغ عن أن الاتصال قائم، والمسار موجود بالقفزة التالية المقصودة، والنظير يُبلغ عن أن المرحلتين 1 و2 قائمتان.

نفق قائم مع تعطل المرحلة 2 يعني أن الجانبين يختلفان حول المحددات:

• أحد الجانبين يسرد شبكة فرعية لا يسردها الآخر.
• أحد الجانبين يستخدم تجميعًا ضيّقه الآخر.
• المسار موجود لكنه يشير إلى نفق مختلف.

Classic VPN نفق واحد باتفاقية مستوى خدمة أقل من HA VPN، وHA VPN يستخدم واجهتين ونفقين وBGP بأنواع موارد مختلفة. ونسخ مثال كلاسيكي إلى إعداد HA وتوقع أن تتصرف حقول المحددات بالطريقة نفسها خطأ منفصل يستحق التجنب. أما حقول النفق نفسها فموثقة في مرجع google_compute_vpn_tunnel.