ماژول ASA FirePOWER مسیر مدیریتی به FMC ندارد

FMC ماژول را غیرقابل‌دسترس نشان می‌دهد، ثبت در حالت در انتظار می‌ماند، و ping از داخل ASA بی‌عیب کار می‌کند. در یک استقرار موجود ASA FirePOWER این ترکیب طبیعی است. ماژول آدرس مدیریت خودش، دروازهٔ پیش‌فرض خودش و تصمیم‌های مسیریابی خودش را دارد، و اشتراک یک اتصال فیزیکی مدیریت با ASA در برخی پلتفرم‌ها آن‌ها را در یک پشتهٔ شبکه ادغام نمی‌کند. دو دستگاه از دو دیدگاه متفاوت روی همان سیم پاسخ می‌دهند.

آنچه در ادامه می‌آید دربارهٔ ماژول‌هایی است که پیش‌تر در حال سرویس هستند. پیش از اعمال هر نمودار پورتی از یک راهنما، مدل شاسی، نوع ماژول و نسخهٔ نرم‌افزار پشتیبانی‌شده را مشخص کنید.

ماژول را به‌عنوان میزبان جداگانه رسم کنید

نمودار را با IP مدیریت ماژول، ماسک و دروازهٔ پیش‌فرض، VLANی که واقعاً آن اتصال را حمل می‌کند، و آدرس FMC که باید به آن برسد آغاز کنید. سپس در کادری جداگانه آدرس‌های رابط ASA و جدول مسیریابی کامل آن را بنویسید. اگر دو کادر در نهایت یک زیرشبکه با آدرس‌های متعلق به طرف‌های مختلف را شریک شوند، بخش جالب مسئله را یافته‌اید.

راهنمای ماژول ASA FirePOWER نشان می‌دهد چیدمان پورت‌ها میان پلتفرم‌ها چگونه تفاوت دارد، از جمله سیم‌کشی مدیریت مشترک که در آن ASA و ماژول آدرس‌های جداگانه در همان سگمنت دارند. آن نمودار سخت‌افزاری ورودی طراحی است، نه پانویس.

پیدا کنید مسیر بازگشت کجا قطع می‌شود

چیدمانی با مسیریابی هسته‌ای را در نظر بگیرید. ماژول ترافیک رو به FMC را به یک هستهٔ Layer 3 می‌فرستد، هسته مقصد مدیریت راه‌دور را به سمت رابط داخلی ASA هدایت می‌کند، و VPN سایت آن را به طرف دیگر می‌برد. سپس سایت راه‌دور به مسیری بازگشتی به زیرشبکهٔ مدیریت ماژول نیاز دارد. هر گام در این زنجیره می‌تواند درست باشد در حالی که آن مسیر آخر غایب است، و به همین دلیل این خرابی اغلب شبیه تونل شکسته به نظر می‌رسد.

پیش از تغییر هر چیزی، دیدگاه خود ASA را بخوانید:

show interface ip brief
show route
show running-config interface

فرمان سوم مهم است، زیرا آدرس رابطی که فراموش کرده‌اید دقیقاً همان چیزی است که مسیر بازگشت را روی دستگاه اشتباه فرود می‌آورد.

بررسی کنید ASA چه چیزی را متصل می‌داند

اگر ASA در زیرشبکهٔ مدیریت ماژول آدرسی داشته باشد، مسیر متصل آن مالک آن پیشوند است. یک مسیر ایستا به سمت هسته مالکیت مسیر متصل را جابه‌جا نمی‌کند، بنابراین بسته به ASA بازمی‌گردد و همان‌جا متوقف می‌شود. آن‌گاه ثبت در نقطه‌ای شکست می‌خورد که هیچ ارتباطی با اعتبارنامه‌ها ندارد.

نتیجه نگیرید که یک بررسی مشخص ضد جعل بسته را انداخته است، مگر آنکه مشاهدات خود دستگاه را پیش روی داشته باشید. در عوض رابط ورودی، مسیر مقصد انتخاب‌شده و مرز پشتیبانی‌شدهٔ ارسال میان مدیریت و داده را برای آن پلتفرم مقایسه کنید. این سه واقعیت معمولاً تعارض توپولوژی را پیش از آنکه کسی بازنشانی کلیدهای ثبت را آغاز کند آشکار می‌کنند.

اصلاحی انتخاب کنید که ماژول را متصل نگه دارد

برداشتن آدرس ASA از آن سگمنت و غیرفعال‌کردن فیزیکی یک پورت مشترک دو اقدام هم‌ارز نیستند. در پلتفرم‌هایی که ماژول از همان اتصال فیزیکی مدیریت عبور می‌کند، غیرفعال‌کردن پورت تنها پیوند ماژول را حذف می‌کند — یک مسئلهٔ مسیریابی را به دستگاهی مرده تبدیل کرده‌اید. تغییری را ترجیح دهید که مالکیت مسیریابی مدیریت را بازتخصیص می‌دهد، و آن را با حضور مالک شبکه آماده کنید.

گزینهٔ پشتیبانی‌شدهٔ دوم این است که به مسیر اداری ASA سگمنت خودش را بدهید تا زیرشبکهٔ مدیریت ماژول یک مالک داشته باشد. این کار یک آدرس و کمی مستندسازی هزینه دارد و ابهام را برای همیشه برمی‌دارد. هر مسیری که انتخاب کنید، پس از آن تأیید کنید که ماژول هنوز هم به FMC و هم به منابع DNS یا NTP خود می‌رسد.

فقط پس از منسجم شدن مسیر ثبت کنید

وقتی مسیر بازگشت پاک شد، اتصال مدیریت و پارامترهای ثبت را از راهنمای نسخهٔ متناظر FMC و ماژول برنامه‌ریزی کنید. اسرار ثبت را از یادداشت‌ها و تیکت‌های مشترک بیرون نگه دارید و در برابر وسوسهٔ ثبت دوباره به‌عنوان گام تشخیصی مقاومت کنید: کلید تازه روی مسیر شکسته فقط همان خرابی را با برچسب زمانی تازه‌تر تولید می‌کند.

مسیر را از پشتهٔ مدیریت خود ماژول بپذیرید نه از pingی که ASA آغاز کرده، زیرا منبع آزمون همان چیزی است که زیر شک است. گام بعدی ماژول، انتخاب VPN در ASA و مسیر پاسخ FMC را ثبت کنید و برای هر دو نقش مدیریت روش بازیابی مستقلی نگه دارید. همان ثبت است که انتقال تعمیرشده را از ثبت موفق جدا می‌کند.

وقتی ماژول سرانجام در FMC ظاهر شد، همان سه فرمان را دوباره اجرا کنید و خروجی را کنار نمودار ذخیره کنید. نفر بعدی که به آن سگمنت مدیریت دست بزند دقیقاً به همین مقایسه نیاز خواهد داشت.