مسألة
تفشل محاولات دفع عمليات النشر إلى أجهزة الدفاع المتعددة ضد تهديدات جدار الحماية (FTD)، مع حدوث حالات فشل في النشر بين 8٪ و 20٪. لا توفر سجلات FMC سببا واضحا لهذه الإخفاقات.
البيئة
- جدار الحماية الآمن من Cisco (FMC)
- تتصل FMC و FTDs عبر مسار MPLS
- عدم فحص جدار الحماية على حركة مرور بيانات SFTUNNEL/الإدارة بين FMC و FTDs
- نطاق ترددي كاف بين FMC و FTDs لاتصالات النفق الآمنة
- تمت ملاحظة حالات فشل النشر
قرار
يوفر سير العمل هذا إجراء شاملا ومفصلا لتحديد حالات فشل النشر من FMC إلى أجهزة FTD المقترنة بمشكلات اتصال عملية sftunnel وحلها. يتم شرح كل خطوة بالتفصيل، بما في ذلك على سبيل المثال مخرجات الأوامر للتوضيح.
الوصول إلى واجهة سطر الأوامر (CLI) الخاصة ب FTD كمستخدم متميز جذري
لإجراء التشخيصات المتقدمة وعمليات المعالجة، قم بتسجيل الدخول إلى واجهة سطر الأوامر (CLI) لجهاز FTD وصعد الامتيازات إلى الجذر.
> expert
device$ sudo su
Password:
root@device:/Volume/home/admin#
التحقق من حالة FTD sftunnel
قم بتشغيل البرنامج النصي sftunnel_status.pl للتحقق من حالة الصحة والاتصال لعملية sftunnel.
root@device:/Volume/home/admin# sftunnel_status.pl
OR
root@device:/Volume/home/admin# sftunnel_status.pl PEERIPADDRESS
OR
root@device:/Volume/home/admin# sftunnel_status.pl PEERUUID
إخراج المثال الذي يشير إلى حالات فشل حالة RPC:
peer UUID did not reply at /ngfw/usr/local/sf/bin/sftunnel_status.pl line 309.
Retry rpc status poll at /ngfw/usr/local/sf/bin/sftunnel_status.pl line 315.
**RPC STATUS****PEERIP*************
RPC status :Failed
**RPC STATUS****PEERIP*************
RPC status :Failed
تأكد من عدم وجود أي تغييرات حديثة في عنوان IP أو الشبكة إلى إدارة FMC أو FTD لأن هذا يتطلب تغيير عنوان IP يدويا على نظام FMC / التكوين / واجهات الإدارة أو FTD CLISH، اعتمادا على الجهاز الذي يتطلب التغيير.
مثال على تغيير عنوان IP للإدارة على FTD CLISH:
> configure network ipv4 manual IPADDRESS NETMASK GATEWAYIP
> show network
تحديد معرف العملية الحالية (PID) لعملية النفق السريع
لمراقبة عملية SFtunnel والتحقق منها، قم باسترداد PID الخاص بها باستخدام PMTOOL.
root@device:/Volume/home/admin# pmtool status | grep sftunnel
مثال الإخراج:
sftunnel Running PID: 12345
إعادة تشغيل عملية SFtunnel والتحقق من تغيير PID
قم بإعادة تشغيل عملية SFtunnel لإعادة تعيين حالة الاتصال الخاصة بها. بعد إعادة التشغيل، قم بإعادة تشغيل التحقق من PID لتأكيد وجود عملية جديدة نشطة.
root@device:/Volume/home/admin# pmtool restartbyid sftunnel
بعد فترة وجيزة، تحقق من حالة العملية مرة أخرى:
root@device:/Volume/home/admin# pmtool status | grep sftunnel
مثال مخرجات (يجب أن يكون PID مختلفا عن السابق):
sftunnel Running PID: 67890
انتظر دقيقتين حتى يتم تثبيت عملية SFTUNNEL وحاول عملية نشر جديدة من FMC إلى FTD المتأثرة
السماح لمدة دقيقتين تقريبا لعملية SFTUNNEL لإعادة تهيئة الاتصال بالكامل وإعادة إنشائه. ثم بدء عملية نشر جديدة من FMC إلى FTD.
مثال على نص النشر:
===============TRANSACTION INFO===============
Device UUID: PEERUUID
Transaction ID: 4075925334520
Selected policy group list: Access Control Policy, Intrusion Policy, Network Analysis Policy, Intrusion Policy
Out-of-date policy group list: Access Control Policy, Intrusion Policy, Network Analysis Policy, Intrusion Policy
Deployment Type: Full Deployment
================================================================
في حالة نجاح النشر، يتم إكمال النشر دون أخطاء ويتم تحديث السياسات على FTD.
التحقق من صحة إعادة تشغيل إتصالات SFTUNNEL و RPC
بعد عملية نشر ناجحة، تأكد من صحة عملية sftunnel وحالة RPC باستخدام sftunnel_status.pl مرة أخرى.
root@device:/Volume/home/admin# sftunnel_status.pl
مثال المخرج يشير إلى النجاح:
**RPC STATUS****PEERIP*************
'ipv4_1' => 'PEERIP',
'uuid' => 'PEERUUID',
'ipv6' => 'IPv6 is not configured for management',
'active' => 1,
'ip' => 'PEERIP',
'last_changed' => 'Thu Nov 13 23:22:43 2025',
'name' => 'PEERNAME',
'uuid_gw' => ''
كرر إجراء إعادة تشغيل FTDs ل كافة المتأثرين
في حالة تأثر العديد من تطبيقات FTD، قم بتنفيذ الخطوات المذكورة أعلاه لكل جهاز متضرر لاستعادة وظائف النشر.
التحقق من صحة النطاق الترددي والاتصال
قم بتشغيل bandwidth_analyzer.pl —حجم SIZEINMB -p Peerip لضمان توفر نطاق ترددي كاف واتصال شبكة أساسي بين FMC و FTDs. تقترح وثائق Cisco سعة معالجة بسرعة 5 ميجابت في الثانية على الأقل للحصول على اتصال إدارة مستقر.
مثال على إخراج تحليل النطاق الترددي:
======== Bandwidth Analysis Result ========
$VAR1 = {
'PEERIP' => [
{
'download' => '3.81 Mbps'
},
{
'upload' => '4.24 Mbps'
},
{
'rpcStatus' => 'Up'
}
]
};
السبب
يمكن أن ترجع الأسباب الجذرية لفشل النشر إلى:
- عطل في عملية SFTD أو FMC معينة.
- التداخل مع حركة مرور بيانات إدارة TLS، مثل عمليات فحص جدار الحماية الوسيطة، مما يتسبب في استجابات خاطئة لعمليات فحص حالة RPC.
- تغييرات الشبكة مثل تغييرات عنوان IP أو عمليات الترحيل أو إضافات الأجهزة التي تتسبب في عدم إمكانية الوصول بين الأجهزة.
يمكن لإعادة تشغيل عملية SFTUNNEL على FTD/FMC المتأثرة إستعادة الاتصال المناسب والسماح بنشر السياسة بنجاح من FMC.
وإلا، فتأكد من الاتصال المناسب بين الأجهزة عن طريق التحقق من صحة عناوين IP ومسار شبكة واضح.
المحتوى ذي الصلة
التعليقات