أستكشاف أخطاء عمليات نشر سياسة الدفاع عن تهديد FirePOWER وإصلاحها

المقدمة

يصف هذا المستند نظرة عامة عالية المستوى على عملية نشر السياسة في FTD بالإضافة إلى تقنيات أستكشاف الأخطاء وإصلاحها الأساسية. 

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• Firewall Management Center (FMC)
• Firepower Threat Defense (FTD)

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

باستخدام Cisco Firepower Threat Defense (FTD)، يتم الآن دمج ميزات جدار الحماية التقليدية التي تحدد الحالة التي توفرها Adaptive Security Appliances (ASA) وميزات جدار Next-Gen الحماية (التي يتم تشغيلها بواسطة Snort ) في منتج واحد. ونظرا لهذا التغيير، Policy Deployment Infrastructure يعالج FTD الآن تغييرات التكوين لكل من رمز ASA (المشار إليه أيضا باسم LINA)، وفي Snort حزمة واحدة. 

نظرة عامة على نشر النهج

يستخدم برنامج FTD من Cisco Policy Deployments لإدارة تكوينات الأجهزة المسجلة في وحدة التحكم Firewall Management Center (FMC) نفسها ودفعها للخارج.

أما داخل عملية النشر، فهناك سلسلة من الخطوات التي يتم تقسيمها إلى مراحل.

يمكن تلخيص مراحل FMC في هذه القائمة.

المرحلة 0	تهيئة النشر
المرحلة الأولى	مجموعة كائنات قاعدة البيانات
المرحلة الثانية	السياسة ومجموعة الكائنات
المرحلة الثالثة	إنشاء تكوين سطر الأوامر NGFW
المرحلة 4	إنشاء حزمة نشر الأجهزة
المرحلة 5	إرسال حزمة النشر واستقبالها
المرحلة 6	النشر وإجراءات النشر ورسائل نجاح النشر المعلقة

يمكن أن تساعد معرفة المراحل وموقع حالات الفشل في العملية في أستكشاف أخطاء الفشل التي يواجهها Firepower النظام وإصلاحها.

في بعض الحالات، يكون التعارض بسبب التكوينات السابقة أو سببه Advanced Flex Configuration افتقار الكلمة الأساسية التي يمكن أن تتسبب في حالات فشل لا يتناولها تقرير الجهاز.

مثال نظرة عامة

الخطوة 1. انقر Deploymentفوق، والذي يحدد الجهاز الذي سيتم تحديده.

الخطوة 2. عند الالتزام بعملية النشر للجهاز، تبدأ FMC في جمع جميع التكوينات المتعلقة بالجهاز. 

الخطوة 3. عندما يتم تجميع التكوينات، تقوم وحدة التحكم في إدارة الهيكل (FMC) بإنشاء الحزمة وإرسالها إلى المستشعر عبر آلية الاتصال الخاصة بها والتي يطلق عليها SFTunnel.

الخطوة 4. يقوم FMC بإعلام المستشعر ببدء عملية النشر باستخدام السياسة المتوفرة أثناء إستماعه للاستجابات الفردية.

الخطوة 5. يفك الجهاز المدار الأرشفة ويبدأ في تطبيق التكوينات والحزم الفردية.

ألف - النصف الأول من النشر هو التكوين الذي Snort يجري فيه إختبار Snort التكوين محليا لضمان صلاحيته.

Snort. عند إثبات صحة التكوين الجديد، يتم نقله إلى دليل الإنتاج لأنه في حالة فشل التحقق من الصحة، يفشل نشر النهج في هذه الخطوة.

ب. النصف الثاني من حمل حزمة النشر خاص بتكوين LINA حيث يتم تطبيقه مباشرة على عملية LINA بواسطة عملية NGFWmanager.

في حالة حدوث فشل، يتم التراجع عن التغييرات ويحدث فشل في نشر النهج.

الخطوة 6. إذا نجح كل من Snort وحزم LINA، يشير الجهاز المدار Snort إلى إعادة التشغيل أو إعادة التحميل من أجل تحميل التكوين الجديد وحفظ جميع التكوينات الحالية.

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

الخطوة 8. بمجرد تلقيها، تحدد FMC المهمة على أنها ناجحة وتسمح لمجموعة السياسات بالإنهاء.

استكشاف الأخطاء وإصلاحها

المشاكل التي تتم مواجهتها خلال Policy Deployment هذه الفترة يمكن أن ترجع إلى، ولكن لا تقتصر على، ما يلي:

1. تكوين خاطئ
2. الاتصال بين FMC و FTD
3. سلامة النظام وقواعد البيانات
4. عيوب البرامج والتحذيرات
5. حالات فريدة أخرى

يمكن إصلاح بعض هذه المشاكل بسهولة، في حين يمكن أن تتطلب أخرى مساعدة من Cisco Technical Assistance Center (TAC).

الهدف من هذا قسم أن يزود تقنية أن يعزل الإصدار أو يعين الجذر سبب. 

واجهة المستخدم الرسومية (GUI) لوحدة التحكم FMC 

توصي Cisco ببدء تشغيل كل جلسة أستكشاف أخطاء النشر وإصلاحها على جهاز FMC.

في إطار "إعلام الفشل"، في جميع الإصدارات بعد 6.2.3، هناك أدوات إضافية يمكن أن تساعد في حالات الفشل الأخرى المحتملة. 

إستخدام محاضر التوزيع

الخطوة 1. اسحب القائمة Deployments على واجهة مستخدم ويب FMC.

الخطوة 2. أثناء تحديد Deployments علامة التبويب، انقر فوق Show History.

الخطوة 3. داخل Deployment History المربع، يمكنك مشاهدة جميع عمليات النشر السابقة من وحدة التحكم في إدارة اللوحة الأساسية (FMC). حدد النشر الذي ترغب في رؤية مزيد من البيانات فيه.

الخطوة 4. بمجرد تحديد عنصر نشر، يعرض Deployment Details التحديد قائمة بجميع الأجهزة داخل Transaction. يتم تقسيم هذه الإدخالات إلى هذه الأعمدة: Device Number, Device Name, Status,و Transcript.

الخطوة 5. حدد الجهاز المعني وانقر فوق خيار النص للاطلاع على نص النشر الفردي الذي يمكنه إبلاغك بالأعطال وكذلك التكوينات التي يتم وضعها على الأجهزة التي تتم إدارتها.

 

الخطوة 6. يمكن أن تشير هذه النسخة إلى حالات فشل معينة وكذلك إلى رقم مهم جدا للخطوة التالية: Transaction ID.

الخطوة 7. Firepower Deploymentفي a، Transaction ID هي ما يمكن إستخدامه لتعقب كل قسم على حدة من نشر السياسات. مع هذا، على سطر أوامر الجهاز، يمكنك الحصول على إصدار أكثر تعمقا من هذه البيانات لمعالجة البيانات وتحليلها.

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

أستكشاف الأخطاء وإصلاحها باستخدام سجلات FMC

على الرغم من أنه من المناسب إشراك Cisco TAC لتحليل السجلات، فإن البحث عبر السجلات يمكن أن يساعد في عزل المشكلة الأولية وتسريع الحل. هناك العديد من ملفات السجل على FMC التي تكشف تفاصيل حول عملية نشر النهج.

اللوحان المشار إليهما بشكل شائع هما policy_deployment.log و usmsharedsvcs.log.

يمكن عرض جميع الملفات المذكورة في هذا المستند باستخدام أوامر Linux المتعددة مثل more، less و vi. بيد أنه من المهم جدا ضمان عدم القيام إلا read بالإجراءات اللازمة لذلك. تتطلب كافة الملفات الوصول الجذر لتتمكن من عرضها.

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

يحدد هذا السجل بوضوح بداية مهمة نشر السياسة على FMC وإكمال كل مرحلة، مما يساعد على تحديد المرحلة التي تعرض فيها النشر للفشل، بالإضافة إلى رمز الفشل.

يمكن إستخدام transactionID القيمة المضمنة في جزء JSON من السجل للعثور على إدخالات السجل المتعلقة بإحدى محاولات النشر المحددة.

10-May-2024 18:05:31.249,[INFO],(JsonRESTServerResource.java:111)
com.cisco.nm.vms.api.rest.DeploymentServerResource, ajp-nio-127.0.0.1-9009-exec-3
** REST Request [ DC ]
** ID : e45c6abd-0fff-4341-bdad-ddd5fee10034
** URL: POST https://localhost6/csm/api/deploy/GetTranscript
{
"data": {},
"deviceUUID": "49243dac-0ba7-11ef-af54-a592d78081a7",
"jobID": 34359753974,
"offset": {
"size": 20,
"start": 0
},
"requestID": "e3be908a0ef711ef9d519da21f9032fa",
"version": "7.2.5"
}

/var/log/sf/policy_deployment.log

وعلى الرغم من وجود ملف السجل هذا خلال إصدارات 6.x التي تبدأ من 6.4، فقد تم توسيع نطاق تغطيته.

وهو يصف الآن الخطوات التفصيلية التي اتخذت بشأن وحدة إدارة الاتصالات الفيدرالية (FMC) لإعداد حزم النشر، وبالتالي فهو يستخدم على أفضل وجه لتحليل حالات الفشل من المرحلة 1-4.

يتم تمييز بداية كل مرحلة بخط مع INFO start.

May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: > SF::UMPD::CSMData::getPolicyRollbackInfo start (161.32M)
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: < SF::UMPD::CSMData::getPolicyRollbackInfo end (161.32M, 0.012(sec))
...

أستكشاف أخطاء الأجهزة المدارة وإصلاحها

هناك مراحل إضافية وأقسام تعتمد على حزمة الأجهزة والتكوين عالي التوافر ونتائج المراحل السابقة لكل جهاز تتم إدارته.

في حالة عزل مشكلة نشر عن فشل على الجهاز المدار، يمكن تنفيذ المزيد من أستكشاف الأخطاء وإصلاحها على الجهاز باستخدام سجلين على الجهاز: policy_deployment.log و ngfwManager.log.

/ngfw/var/log/ngfwManager.log

يوفر ملف السجل هذا الخطوات التفصيلية التي تم إتخاذها من قبل Config Communication Manager وحدة التحكم في إدارة اللوحة الأساسية (FMC) Config Dispatcher وللتواصل معها، والعمل مع حزمة النشر، وتنسيق عملية التحقق من صحة عمليات تهيئة كل من SNORT و LINA وتطبيقها.

هذه بعض الأمثلة على ngfwManager.log التي تمثل بداية المراحل الرئيسية:

FTD receives FMC's request for running configuration:

May 30 16:37:10 ccm[4293] Thread-10: INFO  com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher...
May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>...



FTD receives FMC's request to download the deployment package:

May 30 16:37:18 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236)
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING
May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database



FTD begins the deployment of policy changes:

May 30 16:37:21 ccm[4293] Thread-9: INFO  com.cisco.ccm.ConfigCommunicationManager- Starting deployment
May 30 16:37:21 ccm[4293] Thread-11: INFO  com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager



FTD begins LINA deployment:

May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina



FTD begins finalizing the deployment:

May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher:
Name:Cluster-App-Conf-Finalize-Request

/ngfw/var/log/sf/policy_deployment.log

يحتوي هذا السجل على تفاصيل السياسة المطبقة على Snort. الرغم من أن محتوى السجل متقدم في الغالب ويتطلب تحليلا بواسطة TAC، إلا أنه ما يزال من الممكن تتبع العملية باستخدام عدد قليل من الإدخالات الأساسية:

Config Dispatcher begins extracting the packaged policies for validation:

Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox  (Plugin 230 <- Framework 611 <- Transaction 1085)
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO  found NGFWPolicy =>   (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235)
...
Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13)



Config validation begins:

Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO  starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB)  (Framework 3950<687 <- Transaction 1101 <- main 194)



Validation has completed successfully:

Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) 



Config Dispatcher begins moving the validated configuration to the Snort directories in production:

Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO  -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles  (Plugin 230 <- Framework 822 <- Transaction 1662)



Snort processes will reload to apply the new configurations:

Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9...  (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235)
Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO  sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9  (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235)



Snort reload has completed successfully:

Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200)



After LINA config apply finishes, Snort deployment is finalized:

Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO  starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB)  (Framework 3950<980 <- Transaction 1740 <- main 206)

مثال

الخطوة 1. فشل النشر.

 

 

 

الخطوة 2. الحصول على Deploy Transcript و Transaction ID.

 

الخطوة 3. أدخل بروتوكول SSH Management Center إلى أجهزتك واستخدم أداة Linux المساعدة less لقراءة الملف كما هو موضح على وحدة التحكم في إدارة اللوحة الأساسية (FMC) لديك:

مثال: أقل من ذلك /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log (كلمة مرور sudo هي كلمة مرور المستخدم الخاصة بك ل SSH.)

الخطوة 4. عندما تكون قيد الاستخدام less,شرطة مائلة للأمام وأدخل في معرف الرسالة للبحث عن السجلات المتعلقة بنشر معرف المعاملة. 

مثال: /60129547881 (أثناءless, الاستخدام n للانتقال إلى النتيجة التالية.)

مثال على تشغيل الرسالة

مثال على رسالة الفشل

5) قارن الفشل الصحيح بالجدول المرفق لرسائل الأعطال الشائعة.

 وهذا يعني حدوث failed_to_recovery_running_configuration أثناء حالات فشل الاتصال بين الجهازين. 

رسائل الفشل الشائعة

هذه هي رسائل الفشل الشائعة التي يمكن رؤيتها في الطرف الأمامي من رمز الخطأ Management Center Task وكذلك التي يمكن رؤيتها في الطرف الخلفي.

يمكن تحليل هذه الرسائل ومقارنتها مع الأسباب الشائعة لاتخاذ قرارات محتملة. في حالة عدم رؤية هذه الرسائل أو عدم حلها، يرجى الاتصال ب TAC للمساعدة. 

—

معلومات ذات صلة

محفوظات المراجعة

المراجعة	تاريخ النشر	التعليقات
4.0	02-Sep-2026	إعادة الاعتماد - تنسيق محدث
3.0	13-May-2024	تقويم
2.0	23-Sep-2022	الإصدار الأولي
1.0	17-Feb-2020	الإصدار الأولي