SSH إلى ASA بعيد عبر VPN الموقع: خطوة بخطوة

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

اختر العنوان الذي تديره فعلًا

ثلاثة تصاميم تبدو متشابهة وتتصرف بشكل مختلف: الوصول إلى عنوان ASA العام المواجه لـ VPN، والوصول إلى واجهة داخلية عبر IPsec، والوصول إلى واجهة إدارة مخصصة. اكتب عنوان مصدر المسؤول وعنوان الوجهة الدقيق وTCP 22 قبل أن تلمس أي إذن. كل ما يأتي لاحقًا يعتمد على هذا الزوج.

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

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

management-access خاص بالواجهة

يخبر الأمر management-access جهاز ASA بقبول اتصالات الإدارة على واجهة محددة عندما تصل عبر VPN. وهو لا ينشئ مسارًا، ولا يضيف إذن SSH، ولا ينطبق على كل واجهة في الوقت نفسه. إذا لم تكن واجهة الوجهة هي الواجهة المحددة، يُهمَل الاتصال قبل المصادقة.

استثناءان يظهران هنا. الواجهات المخصصة للإدارة فقط خارج هذه الآلية، ويشير دليل إدارة ASA 9.20 إلى أن حزمة CiscoSSH الافتراضية لا تدعم SSH عبر الواجهات عند المرور بـ VPN بينما تدعمه حزمة ASA SSH. تحقق من الحزمة النشطة على الإصدار المنشور قبل أن تصرف وقتًا على المسارات.

أربع بوابات قبل موجه تسجيل الدخول

بين العميل ومطالبة اسم المستخدم تقف أربع بوابات مستقلة: تطابق المسار والنفق لزوج الإدارة، وقائمة ACL للواجهة تسمح بـ TCP 22 إلى عنوان ASA، وإذن ssh يغطي مصدر المسؤول، ومصادقة AAA لذلك المستخدم. كل واحدة منها يمكنها إسقاط الحزمة دون أن تخبر العميل أي بوابة أُغلقت.

استخدم packet-tracer لمعرفة البوابة التي تفشل قبل أن تغيّر أي شيء: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. يسمّي التتبع قائمة ACL ومرحلة NAT وقرار to-the-box، وهو عادة كافٍ للفصل بين مشكلة توجيه ومشكلة قبول.

اكتب الإذن الضيق، لا الواسع

حدّد الإذن على الشبكة الفرعية الإدارية المعتمدة والواجهة التي تستقبل حركة النفق: ssh 10.10.5.0 255.255.255.0 inside. اقرنه بطريقة مصادقة مثل aaa authentication ssh console LOCAL وحساب محلي مسمّى، بدلًا من فتح كل مصدر على الواجهة الخارجية.

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

تحقق من المضيف المحدد، ثم ضيّق مرة أخرى

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

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