النفق المنقسم لا يعفي مضيفًا عامًا من قواعد NAT على ASA

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

خدمة شريك واحدة على عنوان عام، تصر على رؤية عنوان مقرك، تكفي لتقويض هذه الرواية.

الأسطورة: النفق المنقسم يزيل الجدار الناري من المسار

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

لم يصبح العميل موجهًا. لقد اتبع السياسة التي منحته إياها.

ما الذي يفعله مسار split-include فعليًا

في إعداد الوصول عن بعد على Cisco ASA، تحمل سياسة المجموعة split-tunnel-policy tunnelspecified وكذلك split-tunnel-network-list الذي يسمي قائمة تحكم وصول قياسية. كل سطر permit في تلك القائمة هو وجهة ينبغي للعميل إرسالها إلى النفق، وكل ما عدا ذلك يواصل استخدام المسار الافتراضي المحلي.

إضافة مضيف واحد هي سطر واحد، وهو الجزء الوحيد من التغيير الذي يستطيع العميل رؤيته: access-list RA-SPLIT standard permit host 203.0.113.20.

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

الحزمة تصل وتغادر على الواجهة نفسها

تتبع التدفق الآن بعد فك التشفير. دخلت الحزمة عبر واجهة الخروج من خلال نفق VPN، ووجهتها عنوان عام، ويرسلها جدول التوجيه مرة أخرى عبر الواجهة الخارجية نفسها نحو الإنترنت. تُسقط الحركة التي تدخل واجهة واحدة وتخرج منها ما لم يُسمح لـ ASA بذلك، وهو ما يفعله same-security-traffic permit intra-interface. وبدونه يفشل الاتصال بطريقة تبدو مشكلة توجيه وليست كذلك.

هذا الإعداد عام. فهو يسمح بـ hairpinning لكل تدفق يحتاجه، وليس لهذا المضيف الشريك فقط، لذا ينتمي إلى تغيير مُراجع لا إلى اختبار سريع.

لماذا لا يكون PAT المحدد بالوجهة اختياريًا

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

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

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

جزء destination static مهم. حذفه يحول القاعدة إلى ترجمة واسعة قد تطابق حركة أكثر بكثير مما هو مقصود، وقاعدة identity واسعة تسبقها في الترتيب قد تتغلب عليها تمامًا. تحقق من show nat detail ومن ترتيب الأقسام قبل أن تفترض أن قاعدتك هي المطابقة.

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

أثبت ذلك بوجهة الاختبار الصحيحة

استخدم مضيف الشريك نفسه، لا صفحة what-is-my-ip عامة. تلك الصفحة خارج قائمة الانقسام على الأرجح، لذا تبلغ عن عنوان إنترنتك المحلي ولا تقول شيئًا عن هذا المسار. افتح اتصالًا جديدًا بخدمة الشريك واسألهم ما المصدر الذي لاحظوه، أو شغّل packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed واقرأ مرحلتي NAT والتوجيه سطرًا سطرًا. إن traceroute من العميل فحص أضعف، لأنه يُظهر المسار الذي حدث فعلًا لا السياسة التي اختارته.

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

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