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 نامرتبط دسترسی یکسان پیدا نکرده‌اند، چون مسیر مدیریتی که برای همه کار می‌کند مشکلی متفاوت از مشکلی است که با آن شروع کردید.