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

البوابة البعيدة نقطة تشفير

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

ارسم المسار في ثلاثة أجزاء: من الفرع إلى البوابة القريبة، ومن القريبة إلى البعيدة، ومن البوابة البعيدة إلى التطبيق. ولكل جزء مالكه ونمط فشله.

اقرأ اتجاهي سياسة النفق

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

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

أضف المسار اللاحق وأكّد الإذن

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

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

اختبر من الفرع ثم أعد اختبار المسار القديم

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

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

عيّن مالكًا لكل من الأجزاء الثلاثة ولمسار العودة داخل شبكة الوجهة. المسار الذي له أربعة مالكين يفشل في الفجوات بينهم.

مقالات ذات صلة