السلسلة: هذا الدرس جزء من برنامج «أساسيات Linux 2026». للحصول على نظرة شاملة، اقرأ الدليل الرئيسي أولاً.
مقدمة
حين يُرجع موقع خطأ 502، حين تستجيب واجهة API بعد عشر ثوان بدل خمسين ميلي ثانية، حين يتوقف خادم عن الردّ على ping، السبب نادراً ما يكون واحداً. إنه يختبئ في سلسلة من الطبقات المتعاقبة: واجهة الشبكة، التوجيه، الجدار الناري، تحليل DNS، اتصال TCP، تفاوض TLS، طلب HTTP، استجابة التطبيق. التشخيص يعني النزول طبقة طبقة حتى العثور على الانكسار، لا الاختبار العشوائي. هذا الدرس يعطيك الأوامر، الترتيب، والمنهج، في ثماني خطوات مطبَّقة على خادم Linux حديث (Ubuntu 24.04/26.04 LTS، Debian 13، AlmaLinux 9، Rocky Linux 9).
المتطلبات
- خادم Linux وحساب مع صلاحيات sudo (أغلب أدوات الشبكة تتطلب الامتيازات).
- الحزمة
iproute2(متوفرة افتراضياً على كل التوزيعات الحديثة). - معرفة أساسية بـ TCP/IP: عناوين، منافذ، DNS، HTTP.
- المستوى: مبتدئ متوسط.
- المدة المقدّرة: 90 دقيقة.
الخطوة 1 — فهم الطبقات المراد تشخيصها
قبل كتابة أول أمر، استحضر النموذج المبسّط الذي يقوم عليه كل تشخيص: واجهة فيزيائية ← عنونة IP ← توجيه ← جدار ناري محلي ← منفذ يستمع ← خدمة تطبيقية. أي عطل يسكن في إحدى هذه الطبقات الست، والأدوات تختلف على كل مستوى. القاعدة الذهبية: انزل تدريجياً، ولا تقفز خطوة — curl فاشل لا يخبرك أهو DNS أم TCP أم TLS أم التطبيق. يجب اختبار كلٍّ منها.
هذا الانضباط يميّز تشخيصاً في خمس دقائق من تخبّط ساعة. VPS لا يجيب على curl https://exemple.com قد يعاني: واجهته معطّلة (الطبقة 1)، عنوان IP غير مُسند (الطبقة 2)، طريق افتراضي غائب (الطبقة 3)، جدار ناري يحجب العودة (الطبقة 4)، لا خدمة تستمع على المنفذ 443 (الطبقة 5)، أو Nginx يتعطل في حلقة (الطبقة 6). الأوامر الخمسة في الخطوات القادمة تغطي هذه الطبقات الست في أقل من ستين ثانية.
الخطوة 2 — فحص الواجهات والعناوين
الأمر التاريخي ifconfig مهجور منذ Debian 8 ولم يعد مثبَّتاً افتراضياً. المرجع في 2026 هو ip، يوفّره iproute2. أقوى وأدقّ، ويكشف ميزات حديثة (VLAN، VRF، namespaces) لا يعرفها ifconfig.
ip addr # قائمة الواجهات وعناوين IPv4/IPv6 لها
ip -br addr # نسخة مضغوطة، أوضح
ip link # الحالة الفيزيائية للواجهات (up/down، MAC)
ip -s link show eth0 # إحصاءات الحزم والأخطاء
ip -6 addr # IPv6 فقطمخرَج ip -br addr يسعه بضعة أسطر ويعطي فوراً صورة الشبكة: lo UNKNOWN 127.0.0.1/8 ::1/128 (الحلقة المحلية) وeth0 UP 10.0.0.5/24 fe80::.../64 (الواجهة الرئيسية لـ VPS). إذا ظهر eth0 بـ DOWN أو دون عنوان IP، فلديك خيط أول — الواجهة غير نشطة. ip -s link show eth0 يضيف عدّادات الحزم المستلَمة، المرسَلة، في خطأ والمُهملة؛ عدد كبير من الأخطاء يدلّ على إشكال في العتاد أو في التعريف، نادر في VPS لكنه شائع على baremetal.
الخطوة 3 — التحقق من جدول التوجيه
بعد تفعيل الواجهة، تحتاج الآلة إلى معرفة أين ترسل الحزم لبلوغ الإنترنت. ذلك دور الطريق الافتراضي، الذي يشير إلى بوابة المضيف.
ip route # جدول IPv4
ip -6 route # جدول IPv6
ip route get 1.1.1.1 # أي طريق للوصول إلى 1.1.1.1؟على VPS سليم، ترى عادة سطرين أو ثلاثة: الطريق المباشر داخل الشبكة الفرعية للمضيف (10.0.0.0/24 dev eth0)، والطريق الافتراضي (default via 10.0.0.1 dev eth0). غياب الطريق الافتراضي يفسّر 100% من أعطال «الخادم يَping جاره لكن لا يَping Google». الأمر ip route get 1.1.1.1 مفيد جداً: يحاكي حساب التوجيه لعنوان محدد ويعرض الواجهة، البوابة وعنوان المصدر المختار. إن رجع «Network is unreachable»، فطريقك الافتراضي مفقود أو مكسور.
الخطوة 4 — سرد المنافذ التي تستمع
بعد التأكد من ارتباط الآلة بالإنترنت، تحقّق من أي خدمات تستمع وعلى أي منافذ. الأمر netstat مهجور منذ Debian 8 وبديله الرسمي هو ss، أسرع وأشمل.
ss -tlnp # منافذ TCP في الاستماع، مع PID/البرنامج
ss -tunlp # TCP وUDP، في الاستماع، رقمي، مع PID
ss -s # إحصاءات مجمَّعة للـ sockets
ss -tnp dst :443 # اتصالات TCP نشطة نحو منفذ 443 بعيد
ss -tnp state established # الاتصالات المُنشأةالرايات: -t TCP، -u UDP، -l في الاستماع، -n رقمي (بلا تحليل DNS، أسرع)، -p اسم العملية (يتطلب sudo). مخرَج ss -tlnp هو الانعكاس عند توقف خدمة عن الاستجابة: إذا لم يظهر 0.0.0.0:443، فإن Nginx (أو ما يفترض أن يستمع) ليس مشغّلاً أو يستمع على واجهة خاطئة. التمييز بين 0.0.0.0 (كل الواجهات) و127.0.0.1 (الحلقة المحلية فقط) حاسم: قاعدة PostgreSQL لا تستمع إلا على 127.0.0.1 ستكون غير متاحة من الخارج حتى لو كان المنفذ 5432 مفتوحاً في الجدار الناري.
الخطوة 5 — فحص الجدار الناري
الجدار الناري هو السبب الخفي لنصف أعطال الشبكة: كل شيء معدّ صحيحاً، لكن قاعدة تحجب الاتصال صامتةً. الأمر يعتمد على التوزيعة. على Ubuntu وDebian، الأداة عالية المستوى هي ufw؛ على Alma وRocky، firewalld مع firewall-cmd. كلاهما يقود نفس الآلية الأساسية: nftables (التطور الحديث لـ iptables، المحرّك الافتراضي منذ Debian 10 وRHEL 8).
# Ubuntu / Debian
sudo ufw status verbose
# Alma / Rocky
sudo firewall-cmd --list-all
# المستوى المنخفض (كل التوزيعات)
sudo nft list ruleset # قواعد nftables الفعلية
sudo iptables -L -n -v # الأداة القديمة، ما زالت مفيدة على بعض الأنظمةمخرَج ufw status verbose يعرض القواعد بالترتيب، مع وجهتها وفعلها. إن رأيت «Default: deny (incoming)» ولم يُسمح صراحة إلا للمنفذ 22، فموقعك على المنفذ 443 محجوب حتماً — من هنا تأتي 502 الغامضة. التصحيح: sudo ufw allow 443/tcp؛ لقاعدة أكثر تقييداً بمدى IP محدّد، sudo ufw allow from 1.2.3.4 to any port 5432. لـ firewalld، المكافئ sudo firewall-cmd --permanent --add-service=https && sudo firewall-cmd --reload.
الخطوة 6 — اختبار الاتصال البعيد
في هذه المرحلة، الواجهة، التوجيه، المنافذ والجدار الناري كلها فُحصت من جانب الخادم. يبقى اختبار السلسلة الحقيقية، من الخارج. خمسة أوامر تغطي الأهم.
ping -c 4 1.1.1.1 # اتصال ICMP خام
ping -c 4 google.com # ICMP + DNS معاً
mtr --report --report-cycles 5 google.com # traceroute آني
dig +short example.com # تحليل DNS مباشر
dig +short MX exemple.fr # خوادم بريد مجال
nslookup exemple.com 1.1.1.1 # فرض مُحلِّل معيّن
curl -v https://exemple.com # تفاوض TLS + طلب HTTP بأثر تفصيليالترتيب الانعكاسي: ping على IP خام (الطبقة 3)، ping على اسم نطاق (الطبقة 3 + DNS)، dig منفرداً للتأكد أن DNS يحلّ (يستبعد نصف المسارات الخاطئة)، mtr لرؤية أين تضيع الحزمة بينك وبين الهدف، ثم curl -v للطبقة التطبيقية. أمر curl يفاوض TLS، يرسل الطلب، لكنه يستلم 502 من الخادم: المشكلة تطبيقية لا شبكية. أمر curl يستنفد المهلة على اتصال TCP: المشكلة بين الطبقة 3 و4، تُشخَّص من جانب الخادم. mtr يعرض ضياع الحزم في كل قفزة وسيطة؛ قفزة تنتقل من 0% إلى 90% ضياعاً تحدّد الموجّه المعطوب.
الخطوة 7 — التقاط حركة المرور بـ tcpdump
حين تبدو الطبقات السابقة سليمة لكن المشكلة تستمرّ، النزول إلى مستوى الحزمة ضروري. tcpdump يلتقط حركة المرور الخامة على واجهة — مزعج جداً إذا أُسيء استخدامه، ولا غنى عنه للحالات العنيدة فعلاً.
# رؤية كل حركة HTTPS على eth0 (قطع بـ Ctrl-C)
sudo tcpdump -i eth0 -n port 443
# التقاط 100 حزمة على المنفذ 5432 (PostgreSQL) وكتابتها في ملف
sudo tcpdump -i eth0 -n -c 100 port 5432 -w postgres.pcap
# رؤية طلبات DNS الصادرة
sudo tcpdump -i eth0 -n port 53
# رؤية SYN بلا ACK (مشكل جدار ناري كلاسيكي)
sudo tcpdump -i eth0 -n "tcp[tcpflags] == tcp-syn"الملف .pcap الناتج يُفتح بعد ذلك في Wireshark، الذي يفكّ تشفير كل حزمة ويعرض سلسلة التفاوض مقروءةً. هي الأداة القصوى لفهم لماذا ينقطع عميل بعد SYN ACK أو لماذا يتلقى طلب HTTPS RST غير متوقّع. تحذير: قد يولّد tcpdump عدة جيغابايت في دقائق على خادم محمَّل؛ حدّ دائماً بـ -c (عدد الحزم) أو بمرشّح BPF صارم. على VPS إنتاجي، يجب أن يبقى الالتقاط قصيراً ومركَّزاً.
الخطوة 8 — تحقّق من البداية إلى النهاية
لتأكيد أن ترسانتك تعمل كلها، شغّل التسلسل التالي على خادم اختبار. يختبر كل واحدة من الطبقات الست بالترتيب ويؤكد أن السلسلة الكاملة سليمة.
echo "=== الطبقات 1-2: الواجهة ===" && ip -br addr show eth0
echo "=== الطبقة 3: الطريق الافتراضي ===" && ip route get 1.1.1.1
echo "=== الطبقة 4: المنافذ المستمعة ===" && sudo ss -tlnp | grep -E ":(22|80|443) "
echo "=== الطبقة 4: الجدار الناري ===" && sudo ufw status 2>/dev/null || sudo firewall-cmd --list-all 2>/dev/null
echo "=== الطبقة 5: DNS ===" && dig +short cloudflare.com
echo "=== الطبقة 5: اتصال خارجي ===" && curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://1.1.1.1
echo "✓ كل شيء سليم"على خادم سليم، ترى الواجهة UP، بوابة صالحة، منافذ SSH وHTTP/HTTPS تستمع، قواعد جدار ناري تأذن للمنافذ الضرورية، استجابة DNS، واستجابة HTTP 200 في أقل من ثانية. إن أخفقت إحدى الخطوات، فلديك تحديد دقيق للمشكلة — مما يحوّل تشخيصاً يستغرق ساعتين إلى تصحيح من عشر دقائق.
الأخطاء الشائعة
| الخطأ | السبب | الحل |
|---|---|---|
| «Connection refused» | لا خدمة تستمع على المنفذ | ss -tlnp على الخادم، تشغيل أو إعداد الخدمة |
| «Connection timed out» | جدار ناري يحجب أو طريق غائب | تحقق من ufw status، ip route، وجدار المضيف الناري |
| DNS يحلّ لكن ping يفشل | جدار ناري على ICMP أو خادم معطّل | اختبر ببروتوكول آخر (curl)، افحص السجلات على الخادم |
| خدمة تستمع على 127.0.0.1 وغير متاحة خارجياً | الربط على localhost بدل 0.0.0.0 | عدّل الربط في إعداد الخدمة، أعد التشغيل |
| تأخير مفاجئ | إشباع واجهة أو مشكل توجيه | mtr لتحديد القفزة المعطوبة، ip -s link للعدّادات |
| شهادة TLS مرفوضة | تاريخ نظام خاطئ، شهادة منتهية، أو سلسلة ناقصة | timedatectl، curl -v لرؤية الخطأ الدقيق، تجديد بـ certbot |
| SYN بلا ACK في tcpdump | جدار ناري وسيط يبتلع الحزم | اختبر من نقطة شبكية أخرى، افحص الجدران النارية في الطريق |
دروس ذات صلة
الأسئلة الشائعة
لماذا لم يَعد netstat وifconfig موصى بهما؟
الحزمة net-tools التي توفّرهما في وضع صيانة منذ 2011 ولم تعد مثبَّتة افتراضياً على التوزيعات الحديثة. الأداتان ip وss من iproute2 تكشفان كامل ميزات نواة Linux الحديثة (VLAN، namespaces، multipath routing، BPF)، وهذا ما لا تستطيعه net-tools. تعلَّم الأوامر الجديدة مرة، وستكون جاهزاً في كل مكان.
كيف نرى حركة عملية واحدة؟
الأمر nethogs يصنّف حركة المرور حسب العملية آنياً؛ ss -tnp يدرج الاتصالات النشطة مع PID والبرنامج. لأثر أعمق، strace -e trace=network -p PID يعترض استدعاءات الشبكة لعملية محدّدة. للحاويات، nsenter يدخل namespace شبكة الحاوية ويسمح بتشغيل ss أو tcpdump بداخلها دون تثبيت الأدوات هناك.
كيف نشخّص مشكل DNS؟
أربعة مستويات. cat /etc/resolv.conf يُظهر المُحلِّلات المعدّة. dig @1.1.1.1 exemple.com يختبر مُحلِّلاً محدّداً دون الاعتماد على الإعداد المحلي. dig +trace exemple.com يعيد التحليل التكراري من خوادم الجذر. وأخيراً، resolvectl status على أنظمة systemd-resolved يعطي النظرة الشاملة للمُحلِّلات الفعلية حسب الواجهة.
هل نُعطّل IPv6 على خادم؟
لا. IPv6 مفعّل افتراضياً اليوم على كل المضيفين الجدّيين ويمثّل أغلب حركة المرور لدى بعض المشغّلين (مقياس Google تجاوز 50% من المستخدمين عبر IPv6 نهاية مارس 2026). تعطيل IPv6 يعني عزل نفسك عن جزء من الويب والتباعد عن المعايير الحديثة. الممارسة السليمة هي إعداد الجدار الناري لـ IPv4 وIPv6 معاً (ip6tables أو nft تغطي الاثنين).
كيف نقيس عرض النطاق الفعلي بين آلتين؟iperf3 هي الأداة المرجع. على الخادم: iperf3 -s. على العميل: iperf3 -c adresse-serveur -t 30. الاختبار يدفع حركة لثلاثين ثانية ويعرض المعدل الفعلي بالبت/ثانية. لقياس التأخير والارتعاش، iperf3 -u -b 100M في وضع UDP. هذه الطريقة النظيفة لتقييم عرض النطاق المُعلَن لـ VPS، أو تشخيص اختناق شبكة بين خادمين.
كيف نرى سجل الاتصالات الصادرة من خادم؟
سجل auth.log يتتبّع اتصالات SSH الواردة لكن لا الصادرة التطبيقية. لالتقاطها، نهجان. مع conntrack، تتبّع اتصالات النواة، يمكن استخراج التدفقات النشطة: sudo conntrack -L. لسجل كامل، auditd بقاعدة -a always,exit -F arch=b64 -S connect تكتب كل استدعاء connect() في /var/log/audit/audit.log — طريقة ثقيلة لكنها دقيقة لتحقيقات الأمن.