شبكة VPN للمواقع تعمل لكن سجلات ASA لا تظهر: تحقّق من عنوان المصدر

تصل الأجهزة المضيفة الداخلية إلى المُجمِّع البعيد وتظهر أسطر syslog الخاصة بها. أما رسائل ASA نفسها عن الجلسات ذاتها فلا تصل أبدًا. لا خلل في المُجمِّع ولا في النفق، وهذا هو الجزء المُربك. الجدار الناري يرسل سجلاته من مصدر لم يُبنَ النفق لحمايته قط.

ما يصل وما لا يصل

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

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

الرسالة المُنشأة ليست حركة مرور مُمرَّرة

عندما يُنشئ ASA حزمة، فهو لا يعمل كوكيل لمضيف LAN. يأتي المصدر من واجهة الخروج أو من إعداد مصدر صريح، وتدخل الحزمة في البحث نفسه عن المسار وفحوص السياسة كأي شيء آخر يرسله الجهاز. هذا يعني أن مُحدِّد VPN يجب أن يتضمّن العنوان الذي يستخدمه ASA فعليًا، وهو غالبًا واجهته الخارجية لا شبكة داخلية فرعية.

إذا كانت السياسة تحمي 10.20.0.0/24 وكان ASA يستخدم عنوانه الخارجي مصدرًا، فإن حزمة السجل إما تخرج نصًا صريحًا نحو مُجمِّع لا يستطيع الوصول إليه، وإما تُسقَط. النتيجتان تبدوان متطابقتين من جهة المُجمِّع. المنطق نفسه ينطبق على حركة الإدارة، ولهذا فإن management-access قرار تصميمي منفصل.

أي مصدر يضع ASA على السلك

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

تسمح بعض الإصدارات بتثبيت مصدر التسجيل على واجهة، ومرجع الأوامر لإصدارك هو المرجع في ما إذا كان ذلك الخيار موجودًا وما يغيّره. أمر source-interface من منصة Cisco مختلفة ليس صالحًا تلقائيًا على ASA.

إذا غيّرت المصدر، فغيّره عن قصد وسجّله، لأن قوائم ACL في المُجمِّع وأي ارتباط مبني على syslog يعتمدان عليه.

طابق المُحدِّد مع تدفّق السجل

بعد معرفة المصدر، تحقّق من ثلاثة أشياء بالترتيب: ACL التشفير أو المُحدِّد القائم على السياسة الذي يقرّر أي حركة مرور مهمة، والمسار الذي يقرّر إلى أين تذهب الحزمة، وأي قاعدة NAT قد تعيد كتابة المصدر قبل التشفير. الحزمة التي تطابق المسار ولا تطابق المُحدِّد لا تمر في النفق، والحزمة التي أعاد NAT كتابتها قد لا تطابق أيًّا منهما.

جانب المُجمِّع له متطلباته الخاصة: ACL يسمح بمصدر ASA، ومسار رجوع، وخدمة استماع على المنفذ الذي أعددته. النقل مهم هنا أيضًا، لأن تسجيل TCP وTLS يتصرف بشكل مختلف عن UDP على مسار محجوب جزئيًا. غيّر عنصرًا واحدًا في كل مرة، وإلا فلن يخبرك الالتقاط التالي أي تغيير هو المهم.

تحقّق عند المُجمِّع ثم سجّل المصدر

أكّد وصول الرسالة، ثم اكتب عنوان المصدر الذي استخدمه ASA، والمُحدِّد الذي حملها، ومستوى الخطورة الذي اختبرت به.

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

إن الأسئلة الشائعة حول تسجيل ASA من Cisco توثّق حالة مصدرها خارجي تحتاج تعريف حركة المرور المحمية المقابل، ويتضمّن مثالها بمصدر داخلي كليهما: مضيف تسجيل في الداخل وmanagement-access في الداخل. تعامل مع التوليفة الموثّقة وسياق البرنامج معًا لا بافتراض أن سطرًا منسوخًا واحدًا يناسب كل إعداد.

النفق الذي يحمل حركة LAN ليس نفقًا يحمل صوت الجدار الناري نفسه.