كل حادثة شبكية في الإنتاج — خدمة مصغرة توقفت عن الاستجابة، نشر أحدث تأخيرات، شبكة VPN تفقد الحزم بصمت — تتطلب منهجية تشخيصية منضبطة. المهندسون المخضرمون لا يخمّنون؛ بل يستخدمون سلسلة منظمة من الأدوات تضيّق نطاق المشكلة من "شيء ما خطأ" إلى "فقدان حزم عند القفزة 4 بين us-east-1a وبوابة NAT" في أقل من خمس دقائق. هذا الدرس يزودك بتلك السلسلة: ping، وtraceroute / mtr، وss، وtcpdump.
النموذج الذهني أولاً. قبل تشغيل أي أمر، صغ فرضية: هل هي مشكلة توجيه؟ إسقاط من جدار الحماية؟ منفذ غير مفتوح؟ فشل في TLS؟ كل أداة تجيب على سؤال مختلف. تشغيل tcpdump عندما تكون المشكلة سجل DNS مفقود يهدر دقائق ثمينة أثناء الحوادث.
المستوى الأول من السلسلة — ping: هل المضيف متاح؟
يرسل ping طلبات ICMP Echo ويقيس وقت الرحلة ذهاباً وإياباً (RTT). يجيب على السؤال: هل يمكنني الوصول إلى هذا الـ IP أصلاً، والمسار مستقر؟ في بيئات الإنتاج، غالباً ما يكون ICMP محدود المعدل أو محجوباً بواسطة مجموعات الأمان، لذا فإن فشل ping لا يُثبت بشكل قاطع أن المضيف معطّل — لكن ping يعمل مع ارتفاع RTT أو فقدان حزم متقطع يمثّل إشارة قوية لمشكلة على مستوى طبقة الشبكة.
# إمكانية الوصول الأساسية — إرسال 10 حزم، تقرير ملخص
ping -c 10 10.0.1.45
# Flood ping (يتطلب صلاحيات root) — الكشف عن فقدان الحزم المتفجر
sudo ping -f -c 1000 10.0.1.45
# تحديد حجم الحزمة — الكشف عن إسقاطات متعلقة بـ MTU
ping -s 1400 -c 5 10.0.1.45
# قراءة الناتج
# rtt min/avg/max/mdev = 0.412/0.501/1.243/0.198 ms
# mdev (متوسط الانحراف) > ضعف المتوسط → مشكلة jitter
# فقدان الحزم > 0% → حلقة توجيه أو إسقاط من جدار الحماية
حجم الحزمة مهم. الـ ping الافتراضي بحجم 64 بايت لا يكشف عن ثغرات MTU. الـ ping بحجم 1400 بايت يتجاوز حدود الإطارات الكبيرة ويكشف عن إسقاطات التجزئة التي تظهر فقط تحت أعباء العمل الحقيقية. إذا فشلت الـ ping الكبيرة بينما نجحت الصغيرة، فاشتبه في عدم تطابق MTU — شائع عند حدود نفق VPN وبين مناطق السحابة.
المستوى الثاني — traceroute / mtr: أين ينكسر المسار؟
يستكشف traceroute المسار قفزةً بقفزة عبر إرسال حزم بقيم TTL متزايدة. عندما يصل TTL إلى الصفر، يُصدر كل موجّه رسالة ICMP Time Exceeded، كاشفاً عن IP الخاص به وRTT. استخدمه عندما يُظهر ping فقداناً للحزم أو RTT مرتفعاً لكنك لا تعرف أين في المسار تكمن المشكلة.
يجمع mtr بين ping وtraceroute في عرض تفاعلي فوري. إنه الأداة الإنتاجية المتفوقة لأنه يُظهر فقدان الحزم لكل قفزة عبر الزمن، مما يكشف الأعطال العابرة غير المرئية لتتبع مسار منفرد.
# traceroute قياسي (استعلامات UDP، منفذ 33434+)
traceroute 10.0.1.45
# استخدام استعلامات ICMP (يتجاوز جدران الحماية التي تحجب UDP)
traceroute -I 10.0.1.45
# استخدام TCP SYN على منفذ 443 (يصل عبر معظم جدران الحماية)
traceroute -T -p 443 10.0.1.45
# mtr — تفاعلي، فوري، 100 دورة ثم تقرير
mtr --report --report-cycles 100 10.0.1.45
# mtr مع TCP على منفذ 443 (الأفضل لبيئات السحابة)
mtr --tcp --port 443 --report-cycles 50 api.internal.example.com
# قراءة ناتج mtr:
# Loss% — فقدان الحزم عند هذه القفزة أو قبلها
# Avg — متوسط RTT لهذه القفزة
# StDev — الاهتزاز؛ >5ms للعمود الفقري مثير للقلق
# فقدان عند قفزات وسيطة فقط وليس عند الوجهة النهائية = تحديد معدل ICMP (غير ضار)
# فقدان عند قفزة وسيطة وجميع القفزات بعدها = فقدان حقيقي عند تلك القفزة
الفقدان الوسيط المضلل. كثير من موجهات الشبكة الأساسية تُخفّض أولوية ICMP وستُظهر 20-100% فقدان عند قفزة وسيطة حتى عندما يكون المسار بعدها نظيفاً. القاعدة: إذا أظهرت الوجهة النهائية 0% فقدان، تجاهل الفقدان عند القفزات الوسيطة. أقلق فقط عندما تبدأ الخسارة من قفزة وتستمر في جميع القفزات اللاحقة.
المستوى الثالث — ss: هل العملية تستمع على المنفذ الصحيح؟
يُعدّ ss (إحصائيات المقابس) البديل الحديث لـ netstat. يقرأ مباشرة من جداول مقابس النواة، مما يجعله أسرع وأكثر دقة. استخدم ss للإجابة على: هل العملية مرتبطة فعلاً؟ هل تستمع على الواجهة الصحيحة؟ هل تتراكم اتصالات TIME_WAIT؟
# عرض جميع مقابس TCP المستمعة مع PID
ss -tlnp
# عرض جميع الاتصالات المنشأة على منفذ 5432 (Postgres)
ss -tnp state established '( dport = :5432 or sport = :5432 )'
# عدّ المقابس حسب الحالة — الكشف عن استنفاد الاتصالات
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn
# عرض مقابس UNIX domain (بين العمليات على نفس المضيف)
ss -xlp
# مراقبة أعداد المقابس في الوقت الفعلي (تحديث كل ثانيتين)
watch -n 2 'ss -s'
# الحالات الرئيسية التي يجب معرفتها:
# LISTEN — العملية مرتبطة وتقبل الاتصالات
# ESTABLISHED — اتصال نشط
# TIME_WAIT — اتصال مغلق، نظام التشغيل ينتظر 2×MSL (~60 ثانية على Linux)
# CLOSE_WAIT — الطرف البعيد أغلق؛ العملية المحلية لم تستدعِ close() — خطأ في التطبيق
# SYN_RECV — تم استقبال SYN، انتظار ACK — إذا ظهرت الآلاف فهي فيضان SYN
CLOSE_WAIT في الغالب خطأ في التطبيق. يعني ذلك أن الطرف البعيد أغلق اتصال TCP لكن العملية المحلية لم تستدعِ close() على مقبسها. ستجد هذا عادةً مع تجمعات الاتصالات المعطوبة أو الخدمات التي تُسرّب واصفات الملفات. يحدد ss -tnp state close-wait الـ PID فوراً.
المستوى الرابع — tcpdump: ما هي البايتات على السلك؟
يلتقط tcpdump الحزم الخام عند واجهة الشبكة. إنه أداة الملاذ الأخير — ليس لأنه صعب الاستخدام، بل لأنه يُنتج أعلى دقة على حساب الضجيج. استخدمه عندما تحتاج التأكيد: هل تغادر حركة المرور هذا المضيف فعلاً؟ ما هي الترويسات بالضبط؟ هل تكتمل مصافحة TLS؟ هل يُرسل العميل ما نتوقعه؟
# التقاط كل حركة TCP على eth0 من/إلى منفذ 443، الحفظ في ملف
sudo tcpdump -i eth0 -w /tmp/capture.pcap tcp port 443
# فحص الالتقاط دون اتصال (على جهازك المحلي مع Wireshark أو tcpdump)
tcpdump -r /tmp/capture.pcap -nn -A | head -100
# مشاهدة طلبات HTTP في الوقت الفعلي (نص عادي فقط، وليس HTTPS)
sudo tcpdump -i any -nn -A 'tcp port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420)'
# التقاط حزم SYN — الكشف عن محاولات الاتصال
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and port 8080'
# التقاط حزم RST — الكشف عن اتصالات مرفوضة
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-rst) != 0'
# ناتج مبسّط: بدون DNS (-n)، بدون أسماء منافذ (-n)، مُخزَّن مؤقتاً لكل سطر (-l)
sudo tcpdump -i eth0 -nn -l port 5432 | head -50
# على Pod يعمل في Kubernetes (نمط kubectl exec + nsenter)
kubectl exec -it my-pod -- sh -c "apt-get install -y tcpdump && \
tcpdump -i eth0 -nn -c 100 port 8080"
الجمع معاً: مخطط قرار التشخيص
يلتقط المخطط أدناه المنهجية المنظمة التي يتبعها المهندسون المخضرمون. ابدأ من الأعلى، أجب على كل سؤال بأداة محددة، واخرج بمجرد أن يشير الجواب إلى السبب الجذري.
مخطط قرار تشخيص الشبكة: ping ← mtr ← ss ← tcpdump، بتضييق طبقة الفشل في كل خطوة.
الممارسات الإنتاجية على نطاق واسع
في الشركات الكبيرة، تُلفّ استدعاءات الأدوات الفردية في كتيبات تشغيل وفحوصات صحية آلية. إليك بعض الأنماط التي تستحق الاستيعاب:
التقط أولاً، حلّل لاحقاً. خلال الحادثة النشطة، شغّل tcpdump -w /tmp/incident-$(date +%s).pcap فوراً وافحص الملف بمجرد تخفيف الحادثة. التقاطات الحزم ذهب جنائي وتختفي عند إعادة تشغيل الـ Pod.
أسّس خط أساس لـ RTT. شغّل mtr --report ضد تبعياتك الحرجة أسبوعياً خلال فترات ذروة منخفضة. عند وقوع حادثة، ستعرف إن كانت 5 مللي ثانية لقاعدة بياناتك طبيعية أم مثيرة للقلق.
استخدم ss قبل افتراض وجود جدار حماية. نصف تذاكر "جدار الحماية" هي في الحقيقة خدمات تعطلت وتوقفت عن الاستماع. ss -tlnp | grep 8080 يستغرق ثانيتين ويستبعد تلك الفرضية فوراً.
فضّل -T -p 443 لتتبع مسارات السحابة. مجموعات الأمان السحابية تحجب ICMP وUDP افتراضياً. تتبع مسار TCP على منفذ تستخدمه خدمتك فعلاً هو المسبار الوحيد الموثوق في AWS وGCP وAzure.
لا تشغّل tcpdump في الإنتاج أبداً دون -c أو حد زمني. على واجهة مشغولة، يملأ الالتقاط غير المحدود القرص في دقائق. استخدم -c 10000 أو اضغط الأمر بـ timeout 30 tcpdump ....
المكدّس الذهني المكوّن من 5 طبقات للتشخيص. (1) هل المضيف متاح؟ — ping. (2) أين في المسار؟ — mtr. (3) هل المنفذ مفتوح على هذا المضيف؟ — ss. (4) هل تصل البايتات إلى العملية؟ — tcpdump. (5) هل نجح بروتوكول طبقة التطبيق؟ — سجلات التطبيق / curl -v. اعمل على هذا المكدّس بالترتيب. تخطّي المستويات يهدر الوقت.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية