Cloud VPN إلى جهاز VM على GCP: استخدم عنوان IP الداخلي، لا عنوان NAT

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

ثلاثة عناوين، ثلاث وظائف

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

العنوان الأول ينتمي إلى النفق. والثاني ينتمي إلى تصميم المسار والجدار الناري. والثالث ينتمي إلى الوصول الوارد من الإنترنت، وهو مُعيّن لا مُرفَق. والتصميم الذي يصلح لأحدها لا يقول شيئًا عن الاثنين الآخرين.

لماذا العنوان الخارجي ليس واجهة ثانية

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

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

امشِ المسار باستخدام gcloud

ابدأ من النسخة واقرأ العنوانين من الكائن نفسه، حتى تعرف أيّهما تتحدث عنه وثيقتك:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

ثم أكّد التوجيه والإذن الذي يعتمد عليه المسار فعليًا:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

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

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

بادئة عامة سؤال مختلف

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

هذا ليس مثل معاملة عنوان NAT خارجي عادي كأنه عنوان شبكة فرعية داخلية آخر. الأول بادئة توجّهها؛ والثاني تعيين تطبّقه المنصّة على الوصول الوارد.

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

النطاقات المتداخلة مشكلة مختلفة

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

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

وثّق الحقلين بشكل منفصل

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

تحقّق بعميل حقيقي على الجانب الآخر: حلّ الاسم، وتأكد من أنه يعيد العنوان الداخلي، واتصل، وافحص حركة العودة. تُعد وثائق عناوين IP في Compute Engine المرجع للتمييز بين الداخلي والخارجي المستخدم أعلاه.