تخطَّ إلى المحتوى
netrewind
الصندوق الأسود لشبكتك

المشكلة

حين تتعطّل الشبكة، غالبًا ما نعرف النتيجة ونجهل السبب

انقطع الاتصال الساعة 10:43، ولا نعرف لماذا.

تتوزّع الأدلة بين سجلّات المبدّلات وجدران الحماية وخدمات DHCP وDNS، ولكل مصدر تنسيقه وساعته. وقد تمحو آلية تدوير السجلّات جزءًا مهمًا منها قبل بدء التحقيق.

عندها لا يبقى للمهندس إلا التخمين: يبدّل كابلًا أو يعيد تشغيل خدمة، ثم يعود العطل بعد يومين.

والعطل المتقطّع أسوأ

ينقطع تسعين ثانية كل يومين، في غير وقت معلوم.

من غير العملي انتظار لحظة وقوعه، كما أن التقاط الحزم باستمرار قد يملأ القرص خلال وقت قصير.

لذلك قد يستمر العطل أشهرًا من دون تشخيص واضح.

عند جمع تغيّرات الحالة على خط زمني واحد بدقة النانوثانية، يظهر تسلسل الحادثة بوضوح:

10:41:58  a second DHCP server appeared on 192.168.20.99
10:42:17    nine hosts took a different default gateway
10:42:19      34% packet loss outbound
10:42:23        41 TCP connections to Server X dropped
10:47:12  ended - port Gi0/14 was shut manually

لمن هذا

لمن يحتاج إلى تفسير العطل بعد انتهائه

أين موقعه

ما الذي تقدّمه الأدوات القائمة، وما الذي ينقصها

لكل أداة دور مهم، لكن هذه الأدوات لا تجيب وحدها عن السؤال الذي يظهر بعد انتهاء العطل: ما الذي تغيّر قبله؟

الأداةما تعطيهما لا تعطيه
NetFlow / ntopngإحصاءات حركة المرورلا توفّر سياقًا سببيًا ولا تسجّل حالة الطبقتين الثانية والثالثة
Zeek / Arkimeسجلّات غنية من منفذ SPANتحتاج إلى تخزين كبير، ولا ترى تغيّرات الحالة والإعدادات
Cilium / Pixie / Retinaرصد eBPF ممتازموجّهة إلى الحاويات وKubernetes، ولا تغطي VLAN وARP والمبدّلات التقليدية
SIEMتجميع السجلّاتتحتاج إلى بنية تحتية كبيرة، ويبقى تحليل العلاقة بين السجلّات مهمة المستخدم

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

ما الذي أُنجز

تسجيل وربط من الطبقة الأولى إلى الرابعة، مع اختبارات متكاملة

يقرأ NetRewind حالة الواجهات وجداول الجيران والمسارات والعناوين من netlink، ونتائج الاتصالات من برنامجي eBPF مرتبطين بنقاط تتبّع مستقرة. ويرصد تغيّرات الترشيح عبر فحص قواعد nftables دوريًا، ويجمع بيانات DHCP وDNS وICMP الوصفية من مقبس حزم مُرشَّح. كما يقيس قابلية الوصول بنبضات ICMP مقارنة بخط أساس لكل هدف. ثم تحلل 19 قاعدة ارتباط هذه الأحداث.

يشغّل المختبر 14 سيناريو: 13 عطلًا محقونًا وفترة حركة طبيعية ناجحة للتحقق من خط الأساس. ويجري فحص النتيجة على مرحلتين: التأكد من وجود أثر العطل في السجل، ثم التأكد من أن محرّك الارتباط توصّل إلى الاستنتاج الصحيح. وتضيف طوبولوجيا GNS3، المبنية من موجّهات ومبدّلات Cisco، حالات لا توفرها network namespaces، مثل VLAN حقيقية وOSPF فعلي وانتقال عنوان البوابة بين موجّهين.

sudo make lab
  ok    gateway-hijack               concluded
  ok    contested-address            concluded
  ok    default-route-moved          concluded
  ok    default-route-lost           concluded
  ok    service-unreachable          concluded
  ok    change-broke-a-path          concluded
 
PASS: every injected fault was reconstructed, and correlation named the cause

التحقق الثاني هو الأصعب؛ فوجود الدليل في المخزن لا يعني بالضرورة أن المحرّك استنتج السبب الصحيح منه.

خارطة الطريق

M0
الظرف، والمخزن، وحالة الواجهات، وسطر الأوامر
مُنجَز
M1
الجيران والمسارات والعناوين؛ الهوية الزمنية؛ الاستعلامات السردية؛ مختبر حقن الأعطال
مُنجَز
M2
رصد الاتصالات بـeBPF، والتجميع الدوري، وsystem.drop
مُنجَز
M2b
تغيّرات قواعد nftables؛ والـresets والانقطاعات من tracepoint ثانٍ
مُنجَز
M3
محرّك Isnad بالمطابقة السببية العكسية، ومكتبة من تسع عشرة قاعدة
مُنجَز
M4
مختبر GNS3: نواة OSPF، وVLANs حقيقية، وtrunk، والمسجّل على منفذ وصول
مُنجَز
M5
واجهة الويب، وتصدير Prometheus وOpenTelemetry، وحزم amd64 وarm64، وصورة قابلة للإقلاع
مُنجَز
M5e
التحديث الذاتي من إصدارات موقّعة
مُنجَز

ما يزال دعم conntrack مطلوبًا كي يرى المسجّل على البوابة الاتصالات الممرّرة، لا اتصالات المضيف نفسه فقط. كما يلزم دعم LLDP وSNMP لرؤية طوبولوجيا المبدّلات. يذكر سجل التغييرات هاتين الفجوتين بوضوح.

حدوده

حدود NetRewind الحالية

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

يرى ما يصله
تتوقف قيمة السجل على موضع المسجّل. عند البوابة يرى ما يعبرها، وعلى منفذ مرآة لا يرى قرارات التوجيه والترشيح داخل البوابة، وعلى مضيف عادي لا يرى المحادثات التي لا يكون طرفًا فيها. يشرح دليل التشغيل مزايا كل موضع وحدوده.
مآلات الاتصالات محليّة للمضيف، والسويتشات غير مرئية
ترى نقاط التتبّع مقابس المضيف نفسه فقط. لذلك لا يرى المسجّل على البوابة الاتصالات التي تمر عبرها؛ فهذا يتطلب دعم conntrack غير المتوفر حاليًا. كذلك لا يجمع LLDP أو SNMP، فتظل معلومات منافذ المبدّلات خارج السجل.
تعشية عناوين MAC تكسر التتبّع الطويل
قد تستخدم الهواتف عنوان MAC عشوائيًا لكل شبكة، فلا يستطيع جدول الهويات تتبّع الجهاز نفسه عبر أسابيع. يساعد معرّف عميل DHCP والبصمة السلوكية، لكنهما لا يحلان المشكلة بالكامل.
يفحص مجمّع الترشيح القواعد كل خمس ثوانٍ
لن تظهر القاعدة التي تُضاف ثم تُحذف بين عمليتي فحص. كان البديل هو تحليل مخرجات nft monitor، لكنه حل هش قد يتعطل عند تغيّر صيغة المخرجات. اختير الفحص الدوري لأنه أكثر قابلية للاعتماد، مع توضيح هذه الفجوة.
لم يُشغَّل على شبكة إنتاجية
أُجريت الاختبارات في network namespaces على Linux وفي طوبولوجيا GNS3 تضم موجّهات ومبدّلات Cisco. كما اختُبرت مجمّعات Windows على جهاز فعلي بتوليد تذبذب حقيقي في منفذ الشبكة وتشخيص الحادثة. لكن المنتج لم يُشغَّل بعد في شبكة إنتاجية؛ فاختلافات المصنّعين وحجم الشبكة وأنماط الأعطال الواقعية قد تكشف حالات لا يغطيها المختبر.

توجد قاعدة مخصّصة للتنبيه إلى ذلك أثناء التحقيق: تُطلق recorder-was-blind عند ظهور system.gap أو system.drop بثقة 100%، وتوضح أن سجل هذا المسجّل لا يكفي لاستخلاص نتيجة عن تلك الفترة.

كيف يعمل التوثيق

أسئلة تستحق أن تُسأل

عن المسجّل

ما الذي يسجّله NetRewind بالتحديد؟
يسجّل تغيّرات حالة الشبكة: توقف الواجهات وعودتها، وتغيّر العناوين والمسارات وجدول الجيران (ARP)، إضافة إلى التدفقات وتغيّرات سياسة الترشيح على Linux. ولا يلتقط الحزم أو محتواها.
هل يقرأ محتوى الحزم؟
لا. يقرأ بيانات الاتصال الوصفية، مثل المصدر والوجهة والتوقيت والنتيجة، عبر eBPF وnetlink على Linux أو عبر IP Helper API على Windows. ولا يقرأ محتوى الحزمة.
هل NetRewind مفتوح المصدر؟
نعم، يُنشر كامل المصدر برخصة AGPL-3.0 ولا توجد نسخة مدفوعة. الاتصال الخارجي الوحيد هو فحص يومي اختياري لإصدارات GitHub لمعرفة ما إذا توفرت نسخة أحدث.
ما الفرق بينه وبين tcpdump أو Wireshark أو أدوات SIEM؟
تلتقط tcpdump وWireshark الحزم لتحليلها يدويًا، بينما تجمع أدوات SIEM سجلّات من مصادر أخرى. يعمل NetRewind باستمرار لتسجيل تغيّرات حالة الشبكة وربطها في حادثة واحدة ذات سبب محتمل ومستوى ثقة محدد، من دون حفظ الحزم أو الحاجة إلى خط أنابيب للسجلّات.
هل يتدخّل أي ذكاء اصطناعي في تحديد سبب الحادثة؟
لا. يطابق محرّك الإسناد الأحداث المسجّلة مع قواعد صريحة كتبها بشر. لا يتضمن NetRewind حاليًا أي نموذج ذكاء اصطناعي؛ فالخط الزمني والسلسلة السببية ناتجان بالكامل من القواعد.
ما المنصّات التي يعمل عليها؟
يعمل المسجّل على Linux (x86-64، arm64) وWindows (x64)، ويعمل تطبيق التحقيق لسطح المكتب على كليهما. ولا توجد نسخة لماك من أيّ منهما.

الترخيص والخصوصية

برمجية حرة ومفتوحة المصدر

يصدر NetRewind برخصة AGPL-3.0، ويمكن تشغيله على أي عدد من الأجهزة ولأي مدة، سواء للاستخدام التجاري أو غير التجاري، من دون رسوم ترخيص.

اقرأ الرخصة