التشخيص واستكشاف الأخطاء0%
التشخيص واستكشاف الأخطاء في FortiGate 7.6
عندما يتوقّف الترافيك عن المرور عبر الـ FortiGate، الـ GUI وحده لا يكفي؛ الإجابة الحقيقية تظهر من الـ CLI. في هذه الوحدة نتعلّم أدوات التشخيص الأساسية مثل diagnose sniffer packet و diagnose debug flow وجدول الـ session، ونطبّق منهجية طبقية bottom-up تبدأ من الـ interface وتنتهي عند security profiles. هذا الأسلوب هو ما يميّز المهندس الذي يحلّ المشكلة في دقائق عن غيره.
- 1الـ packet sniffer يعرض الترافيك على السلك مباشرة عبر diagnose sniffer packet <iface> '<filter>' <verbosity> <count>؛ الـ verbosity من 1 إلى 6 يحدّد كمّ التفاصيل، و verbosity 4 يضيف اسم الـ interface وهو الأكثر فائدة في التتبّع.
- 2الـ debug flow يتتبّع رحلة packet واحد داخل النظام: أي firewall policy طابقته، أي route سلكه، أي NAT طُبّق، وسبب الـ drop إن رُفض؛ يُفعَّل بـ diagnose debug flow filter ثم diagnose debug enable.
- 3جدول الـ session هو ذاكرة الـ FortiGate لكل اتصال نشط؛ diagnose sys session filter ثم diagnose sys session list يكشف الـ state و source/destination و NAT والـ policy id، وغياب الـ session لترافيك يُفترض وجوده دليل قوي على مشكلة في policy أو route.
- 4للتحقّق من الـ routing نستخدم get router info routing-table all لعرض الـ FIB الفعلي، و execute ping و execute traceroute لاختبار الوصول من الـ FortiGate نفسه؛ تذكّر أن جدول الـ routing هو ما يقرّر مخرج الـ packet قبل أي policy.
- 5لمراقبة صحّة الجهاز نستخدم get system performance status لقراءة CPU و memory و session count، وندعمها بالـ logs و FortiView لرؤية الترافيك المرفوض والمسموح بشكل بصري؛ ارتفاع الـ CPU أو دخول الـ conserve mode يفسّر سلوكاً غريباً كثيراً.
منهجية استكشاف الأخطاء من الأسفل للأعلى
- ١الـ Interfaceتحقّق من link و speed و duplex والـ VLAN عبر get system interface و diagnose hardware deviceinfo nic.
- ٢الـ ARPتأكّد أن الـ next-hop وُجد على L2 عبر get system arp قبل القلق بشأن الطبقات الأعلى.
- ٣الـ Routingافحص الـ FIB بـ get router info routing-table all لتعرف المخرج الفعلي للـ packet.
- ٤الـ Policy + NATتحقّق من أول firewall policy مطابقة ومن الـ NAT المطبّق عبر diagnose debug flow.
- ٥الـ Profilesأخيراً افحص security profiles مثل IPS و AV و web filter كمصدر محتمل للـ drop.
🔎تفاصيل أعمق
- افصل دائماً بين سؤالين مختلفين: هل الـ packet يصل أصلاً إلى الـ FortiGate؟ وهل الـ FortiGate يُخرجه بشكل صحيح؟ الـ packet sniffer يجيب على الأول لأنه يرى الـ wire بصرف النظر عن المعالجة، بينما الـ debug flow يجيب على الثاني لأنه يكشف منطق المعالجة الداخلي. خلط الأداتين يضيّع الوقت.
- كثير من حالات no traffic ليست أعطالاً معقّدة بل policy مفقودة أو policy في ترتيب خاطئ يلتقطها deny قبلها، أو route ناقص نحو الـ destination. تذكّر أن FortiOS يقيّم الـ policies من الأعلى للأسفل ويتوقف عند أول تطابق، لذا ترتيب الـ policy حاسم.
- احرص دائماً على تحديد filter قبل تشغيل أي debug: استخدم diagnose debug flow filter addr <ip> و port <n>، وبعد الانتهاء نفّذ diagnose debug disable و diagnose debug reset لإيقاف المخرجات وتنظيف الـ filters. تشغيل debug بلا filter على جهاز production قد يُغرق الـ console ويرفع الحمل.
⌨️معمل CLI تفاعلي
اختر مهمة، اكتب الأوامر بنفسك وشاهد النتيجة — أو اضغط «نفّذ التالي».
📖 شرح المهمة والأوامر
الرقم 4 يظهر الترويسة والواجهة، و0 لعدد لا نهائي من الحزم، وa للطابع الزمني المطلق.
diagnose sniffer packet port1 'host 8.8.8.8' 4 0 a— أمر تشخيص
FGT-LAB-01 — FortiOS CLI
# المهمة: التقاط الحزم على واجهة معينة
FGT-LAB-01 #
0/1
أوامر تحقّق من التشغيل (اضغط للتشغيل فورًا):
الرقم 4 يظهر الترويسة والواجهة، و0 لعدد لا نهائي من الحزم، وa للطابع الزمني المطلق.
Packet Sniffer مقابل Debug Flow
Packet Sniffer
- ◆يرى الترافيك على السلك
- ◆يجيب: هل الـ packet وصل؟
- ◆لا يكشف منطق المعالجة
- ◆verbosity 1 إلى 6
Debug Flow
- ◆يتتبّع معالجة packet واحد
- ◆يكشف الـ policy والـ route والـ NAT
- ◆يُظهر سبب الـ drop
- ◆يحتاج filter ثم debug enable
💡 نصيحة مقابلة: 💡 في المقابلة: لو سُئلت لماذا لا يمرّ الترافيك، لا تبدأ بتخمين الـ security profile. اشرح المنهجية الطبقية bottom-up: interface ثم ARP ثم route ثم matching policy ثم NAT ثم profiles، واذكر أن diagnose debug flow يجمع معظم هذه الإجابات في مخرج واحد. هذا يثبت أنك تفكّر كمهندس، لا كمجرّب عشوائي.