نظرة عامة
يُعد استكشاف مشكلات الاتصال ومراقبة المقابس الشبكية ركيزة أساسية لكل مدير أنظمة لينكس. في التوزيعات الحديثة، تخلت الأنظمة عن أداة netstat العتيقة لصالح أداة ss فائقة السرعة والمبنية مباشرة للتعامل مع نواة النظام. نستعرض في هذا الدليل التطبيقي كيفية استثمار قدرات الأمر ss للكشف عن المنافذ المفتوحة، وتتبع الجلسات النشطة، وربط الاتصالات بالعمليات المشغلة لها باحترافية تامة.
1. إعداد البيئة البرمجية واستعراض الإحصائيات العامة للمقابس
تتوفر أداة ss كجزء أساسي من حزمة iproute2. للبدء، نتحقق من وجود الحزمة وتحديثها إلى أحدث إصدار متاح عبر مدير الحزم في أوبونتو:
تتميز أداة ss بقدرتها على قراءة بيانات المقابس مباشرة من مساحة النواة، مما يمنحها سرعة استثنائية مقارنة بالأدوات القديمة. يتيح لنا المفتاح -s الحصول على ملخص إحصائي فوري يوضح أعداد المقابس النشطة وتوزيعها حسب البروتوكولات المختلفة.
⚙️ [أهم خيارات ومفاتيح الأداة]
-s : يعرض تقريراً إحصائياً شاملاً للمقابس على النظام (مثل TCP وUDP وRAW).-t : يحصر النتائج في مقابس بروتوكول TCP فقط.-u : يقتصر على إظهار مقابس بروتوكول UDP.-l : يُظهر المنافذ التي في حالة ترقب وانتظار لاتصالات العملاء (LISTEN).-a : يستعرض كافة المقابس دون استثناء، سواء كانت في وضع الانتظار أو متصلة بالفعل.-n : يفرض عرض عناوين IP وأرقام المنافذ بصيغة رقمية متجاوزاً ترجمة أسماء النطاقات والخدمات.-p : يربط كل مقبس بمعرف العملية (PID) واسم البرنامج المسؤول عنه.
2. تنصيب خادم ويب وتتبع منافذ TCP المفتوحة للاستماع
لإجراء فحص عملي واقعي، نقوم بإعداد خادم الويب Nginx وتشغيل خدمته الأساسية لفتح منفذ ويب للتجربة:
عند تمرير التركيبة ss -tl، يقوم النظام بفلترة مقابس TCP المفتوحة والمستعدة لاستقبال اتصالات جديدة، مع إظهار المنفذ باسم الخدمة الشائعة المقابلة له (مثل http أو ssh أو domain).
يُظهر المخرج بوضوح خادم Nginx وهو ينتظر الزيارات الواردة على منفذ الويب الافتراضي http.
إذا أردنا منع النظام من استبدال أرقام المنافذ بأسمائها الوصفية، يكفي إدراج الخيار -n ضمن الأمر ليصبح ss -tln.
هذا الأسلوب يُلزم الأداة بطباعة الأرقام المباشرة (مثل المنفذ 80 عوضاً عن http، والمنفذ 22 بدلاً من ssh)، وهو ما يفضله مهندسو النظم لتفادي أي التباس أثناء الفحص الدقيق.
3. الربط بين المنافذ المفتوحة والعمليات المسؤولة عنها (PID واسم التطبيق)
يكشف تنفيذ الأمر بصيغة ss -tlp عن تفاصيل إضافية غاية في الأهمية، حيث يُرفق بكل منفذ مستمع اسم العملية البرمجية ورقم معرفها (PID).
يُفصح عمود Process بدقة عن ارتباط خادم Nginx أو العمليات التابعة لنظام systemd بالمنافذ المعنية، مما يسهل تشخيص تعارض المنافذ بين التطبيقات.
تُعد التوليفة الشهيرة ss -tulpn الخيار الأكثر شمولاً وشيوعاً بين مديري النظم؛ إذ تدمج مقابس TCP وUDP معاً في حالة الاستماع، مع الاحتفاظ بالقيم الرقمية وإظهار بيانات العمليات والـ PID بصورة متكاملة.
يسمح ذلك برصد سريع وشامل لجميع الخدمات النشطة، بدءاً من خوادم الويب (المنفذ 80) وإدارة الاتصال البعيد SSH (المنفذ 22) وحتى خدمات تحليل النطاقات المحلية مثل systemd-resolve (المنفذ 53).
4. فحص الاتصالات الحية وتصفية النتائج بحسب المنفذ المستهدف
لتوليد حركة مرور واختبار كيفية تعامل الأداة مع الجلسات الجارية، سنقوم بتثبيت أداة curl وتوجيه طلب HTTP داخلي إلى العنوان المحلي للمضيف:
يعرض الأمر ss -ta سجلاً كاملاً لمقابس TCP دون الاقتصار على وضعية الاستماع؛ حيث تشمل النتائج الاتصالات العابرة وحالات الإغلاق مثل TIME-WAIT.
نلاحظ في المخرجات ظهور جلسة مرتبطة بالطلب الأخير عبر العنوان 127.0.0.1:http وهي تقضي فترة الانتظار المقررة في حالة TIME-WAIT تمهيداً للإغلاق التام.
لعزل الاتصالات المفتوحة فعلياً والتي تتبادل البيانات حالياً، نستعين بفلاتر الحالات وننفذ ss -t state established.
بما أن الطلب التجريبي الذي أنجزناه بواسطة curl انتهى على الفور وأُغلقت جلسته، فلن تُدرج أي اتصالات مستقرة ضمن المخرجات في تلك اللحظة.
تتيح صيغ التصفية المتقدمة حصر النتائج بناءً على منفذ المصدر؛ فاستخدام الأمر ss -tln 'sport = :80' يحدد بدقة مقابس TCP المستمعة التي تعمل حصرياً على المنفذ المحلي 80.
هذه التقنية توفر الكثير من الجهد والوقت عند فحص الخوادم الضخمة، حيث تعزل منفذ خدمة Nginx مباشرة وتستبعد مئات المقابس الأخرى غير المعنية.
تناولنا خلال هذا التطبيق العملي كيفية الاعتماد الكامل على الأمر الحديث ss في بيئة أوبونتو لتحليل المقابس والمنافذ الشبكية بكفاءة تفوق الأدوات التقليدية.
ستشكل هذه الأوامر والفلاتر حليفاً قوياً لك في مهام إدارة الخوادم اليومية وتتبع أعطال الشبكة بدقة وسرعة.