تشخيص الاستهلاك غير المعتاد للشبكة: من الوصلة إلى العملية

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

يتتبع هذا المقال التحقيق من الصورة العامة للشبكة إلى عملية محددة. الخطوات التشغيلية ومعايير القرار توصيات تحريرية؛ أما قدرات الأدوات وحدودها فمراجعة بالاستناد إلى الوثائق الأصلية. الأمثلة لا تدّعي إجراء اختبار على شبكة القارئ الفعلية.

لنحدد أولاً معنى الاستهلاك غير المعتاد

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

ميّز بين معدل النقل والحجم المنقول. Mbps معدل، وGB حجم. في الوحدات العشرية، 1 MB/s يساوي 8 Mbps. وقد تكون سعة الخدمة الفعلية أقل من سرعة المنفذ المتفاوض عليها. في وصلة Full-duplex قارن كل اتجاه بسعته الخاصة؛ جمع الدخول والخروج لا يثبت تشبع أحد الاتجاهين.

اختيار الأداة بحسب السؤال

1. مراقبة الواجهات باستخدام PRTG أو Zabbix

ابدأ بواجهات WAN ووصلات الفروع والوصلات الصاعدة والواجهات المرتبطة بالخدمة المتأثرة. الدخول والخروج يُفهمان من منظور الواجهة نفسها. مستشعر SNMP Traffic نقطة بداية في PRTG؛ وفي Zabbix استخدم قالباً مناسباً للجهاز وافحص وحدة خرج العنصر.

إذا كان العنصر يعيد عداد Octet تراكمياً خاماً، فحساب المعدل يتطلب تغير العداد مع الزمن. في Zabbix يمكن استخدام Change per second والتحويل المناسب للوحدة. لا تكرر التحويل على عنصر يحوّله القالب أصلاً إلى bit/s. العلاقة للعداد الخام هي:

bit/s = (counter_now - counter_previous) * 8 / elapsed_seconds

استخدم عدادات 64-bit عند دعمها. قد تخفي فترة الاستطلاع الطويلة اندفاعاً قصيراً داخل المتوسط؛ والفترة القصيرة جداً لها تكلفة مراقبة أيضاً. نوصي بالاحتفاظ بمعدل كل اتجاه إلى جانب الأخطاء والإسقاطات ومعدل الحزم. العتبة الموحدة لجميع الوصلات لا تعوّض خط الأساس الخاص بكل وصلة.

PRTG / SNMP · Zabbix / SNMP · Zabbix / Preprocessing

2. تحديد الأجهزة والوجهات الأعلى استهلاكاً باستخدام NetFlow

يكشف مخطط الواجهة موضع الازدحام، لكنه لا يحدد المستهلك عادةً. إذا دعم الجهاز ذلك، صدّر NetFlow أو IPFIX من نقطة مشاهدة مناسبة إلى جامع متوافق. ضمن نافذة الحادث، رتّب المصادر والوجهات بحسب Bytes ثم افحص الاتجاه. عدد الجلسات أو الحزم وحده لا يقيس الحجم المنقول.

سجّل المصدّر والواجهة المرصودة وموقع الرصد قبل NAT أو بعده وأخذ العينات وتوقيت الجامع. في البيئات المأخوذة بالعينات، يجب أن تطابق إعدادات الجامع المصدّر، وأن تُقرأ النتائج كتقديرات. مشاهدة التدفق في مواقع متعددة لا تعني إنتاج البيانات مرات متعددة؛ جمع جميع المشاهدات دون تمييز قد يكرر احتسابها.

توصيتنا العملية ربط أكبر المستهلكين بمالك الجهاز وسجلات DHCP/IPAM ودور الخدمة. قد يمثل عنوان NAT عام أو Proxy عدة مستخدمين. سجلات التدفق لا توفر عادة محتوى الطلبات بعد فك التشفير؛ وربط الاستهلاك بنشاط بعينه يحتاج إلى دليل من التطبيق أو المضيف.

Cisco / NetFlow · IPFIX · PRTG / Sampling

3. فحص المرور عبر FortiGate باستخدام FortiView

في FortiView اختر أولاً الفترة الزمنية والجهاز أو VDOM ومسار المرور المناسب. تتبّع المصادر والوجهات والتطبيقات والسياسات ضمن الإمكانات المتاحة في إصدارك. الفرز بحسب Bytes يجيب عن سؤال الحجم، بينما Bandwidth يجيب عن سؤال المعدل.

قبل تفسير مخطط فارغ، تحقق من تغطية التسجيل ومصدر البيانات. العرض التاريخي يعتمد على السجلات الموجودة ومكان الاحتفاظ بها؛ غياب البيانات لا يثبت غياب المرور. والمرور الذي لم يعبر هذا الجدار الناري يقع خارج نطاق رؤيته. فسّر تصنيف التطبيق وفق مستوى الرؤية المتاح للأداة.

اسم التطبيق أو بلد الوجهة ليس سبباً كافياً للحظر. نوصي بتتبع المصدر الأعلى استهلاكاً إلى السياسة والوجهة ومالك الخدمة، ثم تقييم أثر أي قيد على العمل الضروري. تختلف القوائم بين إصدارات FortiOS؛ وهذا القسم ليس أمراً لتغيير إعدادات جدار ناري حي.

FortiView / Monitors · FortiView / Logging · FortiOS / Log settings

4. تحليل سلوك النقل باستخدام Wireshark

عندما يتضح الجهاز والمسار ويبقى السبب غامضاً، التقط عينة قصيرة ومحددة النطاق. يجب أن ترى نقطة الالتقاط المرور المعني فعلاً. في Ethernet المحوّل، تشغيل Promiscuous mode على حاسوب عادي لا يكشف جميع مرور Unicast للأجهزة الأخرى. استخدم موقع التقاط مناسباً أو SPAN أو TAP مصرحاً به. مرشح الالتقاط التالي يستخدم عنواناً مخصصاً للتوثيق:

host 192.0.2.25

استبدل العنوان التجريبي بنقطة نهاية مصرح بها. في Statistics راجع Conversations بحسب Bytes والاتجاه، وقارن المعدلات خلال النافذة نفسها باستخدام I/O Graphs. عرض Bits خلال فترة 1 ثانية يساعد على تفسير المعدل. السطران التاليان مرشحا عرض منفصلان، وليسا مرشح الالتقاط السابق:

ip.addr == 192.0.2.25
tcp.analysis.retransmission

البايتات الملتقطة لا تساوي بالضرورة بيانات التطبيق المفيدة أو عداد WAN. فقد الالتقاط وتكرار مرور SPAN وموقع المشاهدة قد تشوه التفسير؛ وعلامة إعادة الإرسال وحدها لا تثبت عطل المسار. فحص أحجام التدفقات وأنماطها لا يتطلب عادة فك محتوى TLS. اجعل الالتقاط محدود النطاق والمدة ومحكوماً بصلاحيات الوصول.

Wireshark / Capture · Conversations · I/O Graphs · Display filters · TCP analysis · Switched Ethernet

5. تحديد عملية Windows باستخدام Resource Monitor

إذا كان المصدر مضيف Windows، افتح Resource Monitor وانتقل إلى Network. رتّب العمليات ذات نشاط الشبكة بحسب Total أو Send أو Receive، ثم حدد العملية وافحص الوجهات المرتبطة بها. قيم B/sec معدلات بالبايت؛ لا تقارنها مباشرة بـMbps للوصلة.

سجّل اسم العملية وPID ووقت المشاهدة والوجهة. مثال PowerShell التالي يربط PID تجريبياً باتصالات TCP الحالية؛ يجب استبدال 4321. لا يقيس المثال استهلاك كل عملية، ولا يقدم قائمة كاملة بمرور UDP:

$trafficProcessId = 4321
Get-Process -Id $trafficProcessId
Get-NetTCPConnection -OwningProcess $trafficProcessId |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State

Resource Monitor يعرض هذا المضيف، لا استهلاك الإنترنت للمؤسسة كلها؛ وقد يشمل مرور LAN المحلي أيضاً. يكمله TCPView بمعلومات نقاط النهاية والعملية المالكة. تعرّف إلى الخدمة وعملها قبل إغلاق أي شيء. أسماء مثل System أو svchost وحدها لا تثبت برمجية خبيثة ولا تبرر الإنهاء.

Microsoft / Resource Monitor · Microsoft / TCPView · Get-NetTCPConnection

6. التمييز بين حلقات الشبكة والبث والتنزيل

إذا تأثرت LAN بشدة ولم يتناسب استهلاك WAN مع الأعراض، فافحص سلوك الطبقة الثانية. قارن معدل الحزم الداخلة وBroadcast وMulticast في المنافذ المتأثرة مع مخطط التوصيلات. قد لا يصل المرور الداخلي إلى جدار الإنترنت أصلاً.

سجلات تغير الطوبولوجيا وانتقال MAC مؤشرات، وليست إثباتاً لمكان بداية الحلقة. نوصي بتتبع معدلات الدخول غير المتوقعة ومراجعة آخر التوصيلات المادية. لا تفصل وصلة صاعدة مجهولة عشوائياً؛ قيّد مقطعاً متحققاً منه فقط مع خطة تراجع.

Cisco / Layer-2 loops

7. ربط الاستهلاك بالنسخ الاحتياطي والتحديثات

قارن بداية المرور بالنسخ الاحتياطي والتكرار والمزامنة السحابية وتوزيع البرامج وWindows Update. قد يكون النقل مصرحاً به لكنه يضر بالخدمة الرئيسية إذا كان توقيته أو تخصيص سعته غير مناسب.

في Delivery Optimization استعن بتقارير Windows وأدواته التشخيصية؛ اسم خدمة مشتركة وحده لا يثبت النشاط المحدد. الاستجابة التي نقترحها هي تأكيد المهمة مع مالكها وتجربة تعديل محدود لجدولها أو معدلها، بدلاً من تعطيل النسخ الاحتياطي والتحديثات الأمنية نهائياً.

Microsoft / Delivery Optimization

8. ربط سجلات التطبيق بأدلة الشبكة

إذا كانت خدمة ويب أو API من كبار المستهلكين، فقارن أوقات الطلبات ومساراتها وحالاتها وأحجام الردود في سجل الوصول أو التطبيق. في NGINX ترتبط متغيرات مثل $body_bytes_sent بحجم جسم الاستجابة؛ عدد الطلبات وحده لا يفسر استهلاك البايتات.

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

NGINX / Access logs · NGINX / Variables

سيناريو افتراضي: المكالمات تتعطل والتنزيل مقبول

لنفترض أن وصلة الخدمة 100 Mbps، وأن المرور الصادر يقترب من 90 Mbps، وأن المكالمات تتدهور بينما يبقى التنزيل مقبولاً. افحص أولاً سعة الاتجاه الصادر؛ سرعة المنفذ الأعلى لا تزيل حد الخدمة.

في هذا السيناريو التعليمي يظهر المضيف التجريبي 192.0.2.25 في مقدمة بيانات التدفق. يؤكد FortiView المرور المطابق في الفترة نفسها. وعلى المضيف تتوافق عملية النسخ الاحتياطي وسجل المهمة مع زمن الحادث. بالاتفاق مع المالك نخفض معدل ذلك النقل مؤقتاً ونعيد اختبار المكالمات ومخطط الخروج. التحسن دليل مفيد، لكن قابلية التكرار والأنشطة المتزامنة الأخرى تحتاج إلى فحص قبل استنتاج موثوق.

مسار عمل مقترح أثناء الحادث

1. سجّل الوقت والمنطقة الزمنية والنطاق المتأثر ومقياس أثر المشكلة على المستخدم.
2. حدّد الواجهة والاتجاه المزدحمين باستخدام المعدلات وخط الأساس والأخطاء.
3. تتبّع النافذة نفسها في سجلات التدفق والجدار الناري، ثم حدد مالك الجهاز.
4. عند الحاجة اجمع أدلة المضيف أو التقاطاً محدوداً، ونفّذ تغييراً قابلاً للتراجع.
5. تحقق من عمل المستخدم الفعلي وتعافي المخططات، ثم عيّن مسؤولية السبب وإجراء الوقاية.

الخلاصة: المستهلك الأكبر ليس بالضرورة المتسبب

نوصي ببناء سلسلة أدلة بدلاً من مطاردة أكبر رقم: الواجهة والجهاز والوجهة والعملية والنشاط الفعلي. هذه السلسلة تميز العمل المشروع سيئ التوقيت عن النقل غير المتوقع أو أعطال الشبكة أو السلوك المشبوه.

قراءة ذات صلة

الخوادم سليمة والمستخدم ينتظر: لماذا لا يكفي متوسط زمن الاستجابة؟