عیب‌یابی Deploy نشدن Policy در Cisco FMC/FTD

پاسخ کوتاه: وقتی Policy در Cisco FMC روی FTD deploy نمی‌شود، اول باید خطای deploy، وضعیت health دستگاه، ارتباط FMC و FTD، تغییرات pending و objectهای وابسته بررسی شود. تغییر دادن چند policy هم‌زمان معمولاً عیب‌یابی را سخت‌تر می‌کند.

در Firepower، deploy فقط یک دکمه ساده نیست. پشت آن Access Control Policy، NAT، intrusion policy، file policy، platform settings، identity و objectهای مشترک قرار دارد. اگر یکی از این بخش‌ها ناسازگار باشد، deploy ممکن است fail شود یا روی یک دستگاه از چند دستگاه انجام نشود.

چرا Deploy در Cisco FMC/FTD حساس است؟

FTD نقطه عبور ترافیک است و تغییر policy می‌تواند روی دسترسی کاربران، VPN، inspection و حتی مسیرهای حیاتی اثر بگذارد. به همین دلیل، عیب‌یابی deploy باید کنترل‌شده باشد. هدف این نیست که با چند تغییر بزرگ خطا را رد کنیم؛ هدف این است که علت دقیق خطا پیدا شود و تغییر قابل برگشت بماند.

علت‌های رایج Deploy نشدن Policy چیست؟

• قطع یا ناپایداری ارتباط management بین FMC و FTD
• وجود object حذف‌شده، تکراری یا ناسازگار در ruleها
• اختلاف نسخه یا patch بین FMC و دستگاه‌های managed
• pending changes قدیمی که با تغییرات جدید قاطی شده‌اند
• مشکل در health module، disk، memory یا processهای inspection
• خطا در NAT، VPN، interface zone یا security intelligence list
• تغییر هم‌زمان چند policy بدون تست مرحله‌ای

چک‌لیست سریع قبل از Deploy دوباره

• متن خطای deploy را ذخیره کنید و فقط به پیام کلی failed اکتفا نکنید.
• در Health Monitor وضعیت FMC و FTD را از نظر connectivity، disk، memory و process بررسی کنید.
• مطمئن شوید دستگاه مورد نظر registered و reachable است.
• تغییرات pending را مرور کنید و اگر زیاد هستند، علت هر بخش را مشخص کنید.
• objectها و ruleهایی را که تازه تغییر کرده‌اند جداگانه بررسی کنید.
• اگر چند دستگاه در یک policy هستند، مشخص کنید خطا روی همه رخ داده یا فقط یک FTD.

روش بررسی قدم‌به‌قدم در FMC چگونه است؟

از deploy transcript شروع کنید. این بخش معمولاً بهتر از پیام خلاصه نشان می‌دهد خطا در مرحله validation، package generation، transfer یا apply رخ داده است. اگر خطا قبل از انتقال package باشد، بیشتر دنبال object، rule، policy یا validation باشید. اگر خطا هنگام transfer یا apply رخ دهد، health و ارتباط دستگاه مهم‌تر می‌شود.

بعد از آن تغییرات اخیر را کوچک کنید. اگر هم‌زمان NAT، Access Control، intrusion و object تغییر کرده‌اند، تشخیص علت سخت می‌شود. در محیط‌های حساس، بهتر است تغییرات بزرگ به چند deploy کوچک‌تر تقسیم شوند تا اگر خطایی رخ داد، محدوده مشکل روشن باشد.

چه زمانی مشکل از دستگاه است و نه policy؟

اگر همان policy روی چند FTD deploy می‌شود اما فقط یک دستگاه خطا می‌دهد، احتمال مشکل device-side بیشتر است: connectivity، resource، registration، process، disk یا نسخه. در این حالت بررسی health و logهای همان FTD از تغییر دادن policy مهم‌تر است.

اشتباهات رایج در عیب‌یابی FMC Deploy

• deploy پشت سر هم بدون خواندن transcript: تکرار deploy معمولاً علت را روشن نمی‌کند.
• تغییر دادن چند بخش برای رد شدن خطا: شاید deploy موفق شود، اما معلوم نمی‌شود کدام تغییر واقعاً لازم بوده است.
• نادیده گرفتن health: گاهی policy سالم است، اما دستگاه managed آماده دریافت یا اعمال تغییر نیست.
• نداشتن rollback ذهنی: قبل از deploy باید بدانید اگر rule اشتباه بود، کدام تغییر باید برگردد.

برداشت عملی از عیب‌یابی Deploy نشدن Policy در Cisco FMC/FTD

برای عیب‌یابی deploy در Cisco FMC/FTD، ترتیب کار مهم است: خطای دقیق، health، connectivity، pending changes، objectهای وابسته و بعد تست محدود. اگر Firepower را در مرز شبکه استفاده می‌کنید، صفحه آموزش Cisco Firepower و مقاله دفاع از مرزهای شبکه می‌توانند تصویر کامل‌تری بدهند. برای مدیریت تغییرات هم مقاله پیکربندی امن تجهیزات شبکه مرتبط است.

واژه‌نامه کوتاه

• FMC: کنسول مدیریت مرکزی Cisco Firepower Management Center.
• FTD: سیستم عامل Cisco Firepower Threat Defense روی فایروال.
• Deploy: فرایند ارسال و اعمال تغییرات policy از FMC به FTD.
• Pending Changes: تغییراتی که در FMC ذخیره شده‌اند اما هنوز روی دستگاه اعمال نشده‌اند.

درباره نویسنده

این راهنما توسط علیرضا عربیان برای تیم‌های شبکه و امنیت نوشته شده است؛ با تمرکز روی عیب‌یابی مرحله‌ای، کاهش ریسک تغییرات و مستندسازی تصمیم‌های فنی.