أوامر الشبكة في لينكس: ip وss وping وtraceroute وdig وcurl للتشخيص

تغطي أوامر الشبكة في لينكس معظم التشخيص اليومي: يعرض ip العناوين والمسارات، ويعرض ss المنافذ المفتوحة والاتصالات، ويتحقق ping وtraceroute من وصول العقدة، ويفحص dig نظام DNS، ويختبر curl استجابة خدمة الويب. فيما يلي مرجع سريع مع الخيارات، وترتيب خطوات يساعدك على العثور على السبب حين «لا تعمل الشبكة».

مرجع سريع: أوامر الشبكة في لينكس في جدول واحد

ip: العناوين والواجهات والمسارات

الأمر ip من حزمة iproute2 حلّ محل الأمرين القديمين ifconfig وroute. يمكن اختصار الأوامر الفرعية: ip a بمعنى ip addr، وip r بمعنى ip route. الخيار -br يعطي مخرجات مختصرة، و-c يلوّنها.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

إذا لم يكن للواجهة عنوان من الشبكة المطلوبة، أو كانت في الحالة DOWN، فلا داعي للبحث أبعد من ذلك — المشكلة موجودة على هذا المستوى.

كيف تضيف عنوان IP وتُفعّل الواجهة

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

التغييرات التي تجريها عبر ip تبقى حتى إعادة التشغيل. أما الإعدادات الدائمة فتُكتب في إعدادات النظام: netplan في Ubuntu، وNetworkManager (nmcli) في Fedora وRHEL، وsystemd-networkd على الخوادم.

المسارات وبوابة الافتراض

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

السطر default via هو البوابة التي تذهب إليها كل الحزم التي لا تطابق مساراً أدق. إذا غاب هذا السطر فلن يكون هناك إنترنت، حتى لو كانت الشبكة المحلية تعمل. لإضافة مسار: sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss: أي المنافذ مفتوحة ومن يستمع إليها

حلّ ss محل netstat وهو أسرع منه. أشهر تركيبة هي ss -tulpn:

$ sudo ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

انتبه إلى العنوان: 0.0.0.0 يعني أن الخدمة تقبل الاتصالات من كل الواجهات، و127.0.0.1 يعني أنها محلية فقط. وهذا سبب شائع لكون قاعدة البيانات «لا تستجيب» من جهاز آخر.

كيف تعرف من يشغل منفذاً

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # الاتصالات إلى عنوان محدد
ss -tan state time-wait | wc -l   # عدد المقابس في حالة TIME-WAIT

ping: هل العقدة متاحة

يرسل ping طلبات ICMP echo ويعرض زمن الاستجابة والفاقد. في لينكس يعمل بلا توقف، لذلك حدّد عدد الحزم بالخيار -c.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

خيارات مفيدة: -i 0.2 للفاصل الزمني، و-W 2 لمهلة الرد، و-4/-6 لإصدار البروتوكول، و-s 1472 -M do لفحص MTU دون تجزئة. تذكّر أن كثيراً من الخوادم والسحابات تحجب ICMP، فغياب الرد على ping لا يعني أن العقدة غير متاحة.

traceroute وmtr: أين تضيع الحزم

يعرض traceroute العقد على طريق الوصول إلى الهدف. النجوم عند بعض القفزات أمر طبيعي، فقد لا يجيب موجّه وسيط. العلامة المقلقة أن تظهر النجوم من قفزة معينة حتى النهاية.

traceroute -n example.com        # بدون أسماء DNS، أسرع
sudo traceroute -T -p 443 example.com   # TCP بدلاً من UDP، يمر عبر الجدران النارية
tracepath example.com            # بدون صلاحيات root، ويعرض MTU أيضاً

يجمع mtr بين ping وtraceroute ويحدّث إحصاءات الفقد لكل قفزة في الوقت الفعلي. لتقرير جاهز: mtr -rwc 50 example.com.

dig: التحقق من DNS

الأداة dig من حزمة dnsutils (وهي bind-utils في RHEL) هي الأداة الرئيسية للتحقق من DNS. الصيغة القصيرة تعرض الإجابة فقط:

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # السؤال عن خادم محدد
$ dig -x 8.8.8.8 +short            # السجل العكسي (PTR)
$ dig +trace example.com           # تتبّع السلسلة من الخوادم الجذرية

في المخرجات الكاملة انظر إلى status: NOERROR يعني أن السجل موجود، وNXDOMAIN يعني أن النطاق غير موجود، وSERVFAIL يعني أن الخادم لم يستطع الرد (غالباً مشكلة في DNSSEC أو خادم موثوق غير متاح). إذا ردّ dig @8.8.8.8 بينما لا يردّ dig العادي، فالمحلل المحلي هو المتهم: راجع /etc/resolv.conf وresolvectl status.

لاحظ أن dig لا يقرأ /etc/hosts. لاختبار تحويل الاسم كما سيفعله التطبيق، استخدم getent hosts example.com.

curl: التحقق من HTTP وAPI

يجيب curl عن السؤال الأخير: هل تردّ الخدمة، وماذا تعيد بالضبط؟

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

رسائل خطأ curl تدل جيداً على الطبقة المعطلة: Could not resolve host تعني مشكلة DNS، وConnection refused يعني أن المنفذ مغلق أو لا أحد يستمع إليه، وConnection timed out يعني أن الجدار الناري يسقط الحزم أو لا يوجد مسار، وSSL certificate problem تعني مشكلة في الشهادة.

ترتيب التشخيص: عندما «لا تعمل الشبكة»

1. الواجهة والعنوان: ip -br addr — الواجهة في حالة UP وللعنوان قيمة.
2. البوابة: ip route — يوجد سطر default via؛ ثم ping -c 3 <البوابة>.
3. الشبكة الخارجية بالعنوان: ping -c 3 1.1.1.1. إذا عمل، فالتوجيه سليم.
4. DNS: dig +short example.com. إذا كانت النتيجة فارغة أو خاطئة بينما يعمل ping بالعنوان، فالمشكلة في المحلل.
5. المنفذ: nc -zv host 443 أو curl -v. وعلى الخادم ss -tulpn لمعرفة هل الخدمة تستمع وعلى أي عنوان.
6. الجدار الناري: sudo nft list ruleset، sudo iptables -L -n، sudo ufw status.
7. التطبيق: curl -I وسجلات الخدمة (journalctl -u nginx).

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

الأوامر القديمة والبدائل الحديثة

في التوزيعات الحديثة كثيراً ما لا تكون net-tools مثبتة أصلاً، لذلك من الأفضل أن تعتاد الأوامر الجديدة.

الخلاصة

يكفي لتشخيص الشبكة اليومي ستة أوامر: ip وss وping وtraceroute وdig وcurl. تحقق طبقة بعد أخرى — العنوان ثم المسار ثم DNS ثم المنفذ ثم التطبيق — وستجد الخطأ بسرعة. وتُعرض أوامر الشبكة وتحليل الأعطال الشائعة عملياً في دورة Linux.