المسار الافتراضي النفقي في Cisco ASA: متى يُطبَّق فعلياً

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

ابدأ من العَرَض لا من الإعداد

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

يبدو النفق سليماً في show vpn-sessiondb، وهذا بالضبط سبب استمرار الناس في تنقيح IKE.

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

كيف يختلف البحث النفقي

يصف دليل التوجيه الثابت في ASA 9.23 التابع لـ Cisco مساراً افتراضياً منفصلاً لحركة VPN المفكوكة التي ليس لها مسار ثابت أو متعلَّم. الكلمة المفتاحية tunneled تعلّم ذلك المسار، لذا يمكن للحزمة المفكوكة أن ترتد إلى قفزة تالية مختلفة عن تلك التي يستخدمها ASA لحركته الخاصة. المسارات الأكثر تحديداً تبقى هي الفائزة، ولهذا يمكن للعميل الوصول إلى 10.0.0.0/8 عبر البوابة الداخلية وفقدان كل شيء آخر.

يحتفظ التصميم الأدنى بمسارين افتراضيين بقفزتين تاليتين مختلفتين. أحدهما يحمل حركة ASA الخاصة، والآخر يحمل الحركة المفكوكة التي ليس لها مسار أفضل. ويجب أن تبقى القفزتان التاليتان قابلتين للوصول من الواجهة التي تربطهما بها.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

إذا أشار المساران الافتراضيان إلى القفزة التالية نفسها، فلا تغير الكلمة المفتاحية شيئاً ولن يتحرك العَرَض.

القيود التي تحدد ما إذا كان سيعمل

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

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

تتبع المسارات فخ منفصل: الكائن المتتبَّع يحرس عادةً المسار الافتراضي العادي لا النفقي.

ما لا تفعله الكلمة المفتاحية

إنها لا تختار عنوان المصدر الذي يستخدمه ASA لبناء IKE. نقطة نهاية النفق الخارجية تتبع اختيار الواجهة والمصدر الخاص بالمنصة، وليس للمسار الافتراضي النفقي أي دور في ذلك القرار. تغييره لن يصلح phase 1 الذي يأتي من العنوان الخاطئ.

ولا تحوّل القفزة التالية إلى وكيل. إذا كانت الوجهة تتوقع تبادل HTTP CONNECT، فإن إرسال حزم IP خامة إلى مضيف وكيل لا يمنحك سوى مضيف لا يوجّهها. اضبط بدلاً من ذلك آلية الوكيل المدعومة لدى العميل.

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

تحقق من المسار من الطرف إلى الطرف

بعد تثبيت المسار، افحص أربعة أمور بالترتيب: show route لوجهة يحتاجها التجمع، والتقاط على الواجهة المتجهة إلى القفزة التالية الجديدة، والتقاط على البوابة نفسها، ومسار عودة من تلك البوابة إلى عنوان التجمع. أول اثنين يثبتان أن ASA اختار المسار، والآخران يثبتان أن أحداً يستجيب عليه.

إذا كانت البوابة تجيب لكن العميل لا يرى أي رد، فانظر إلى ترجمة المصدر ومسار الرد قبل أن تمس جدول التوجيه مرة أخرى.

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