المرحلة 05 — التحكّم والتشخيص

لاحظ

هنا نلتقط ساكناً بقي معلّقاً: من يحمل الأخبار عن الشبكة؟ نكتشف ICMP و ping، ونحلّ لغز 127.0.0.1 / localhost و 0.0.0.0 — وهي مفاتيح مشروع هولبرتون الثاني، وعمود تاسك ping في الأول.

المحتوى

النبذة
الجزء أ — ICMP و ping
الجزء ب — العناوين الخاصّة: 127.0.0.1 و 0.0.0.0
🔗 جسر إلى Bash (لأن تاسك ping سكربت)
الخلاصة وموقعك على الشجرة

النبذة

كل ما بنيناه ينقل بيانات المستخدم. لكن الشبكة تحتاج أن تتكلّم عن نفسها: «حزمتك كانت أكبر من اللازم»، «لا مسار لتلك الوجهة»، «انتهى عمر الحزمة». ومن جهةٍ أخرى، بقي عنوانان غامضان: العنوان الذي يكلّم به الجهازُ نفسَه، والعنوان الذي يعني «كل العناوين». هذه المرحلة تجمعها.

الجزء أ — ICMP و ping

اللغز

أرسلتَ حزمة IP لوجهةٍ لا وجود لها. أو لراوترٍ ممتلئٍ اضطُرّ لرميها. أو لحزمةٍ دارت في حلقةٍ لا نهائية بين راوترين. في كل حالة: كيف يعلم المرسِل بما جرى؟ الـ IP بذل-جهدٍ-فقط: يرمي بصمت. لو بقي الأمر هكذا، لكان تصحيح أي خطأٍ شبكيٍّ استحالةً عمياء.

صمّم: ما الذي تحتاجه الشبكة لتُبلِّغ عن الأخطاء والحالة؟ وعلى أي طبقة يعيش؟

الدرس: ICMP — جهاز الإنترنت العصبي

حلّك لا بد أنه: «نحتاج بروتوكولاً يحمل رسائل التحكّم والأخطاء». اسمه ICMP (Internet Control Message Protocol). خصائصه التي تشتقّها من وظيفته:

يركب فوق IP (طبقة 3) — لأنه يتكلّم عن حزم IP ويسافر مثلها — لكنه ليس لبيانات التطبيقات. ليس له منافذ (ليس TCP/UDP)؛ هو على مستوى IP نفسه.
أنواع رسائله: Destination Unreachable، Time Exceeded، Echo Request/Reply...

إجابة هولبرتون

جواب هولبرتون: ما الأداة/البروتوكول للتحقّق أن جهازاً متّصل بالشبكة؟ ICMP، عبر أمر ping.

ping: اشتقاقه ولماذا يثبت الوصول

ping يستغلّ نوعين من ICMP: يرسل Echo Request، فيردّ الجهازُ الحيّ بـ Echo Reply. وصول الرد يثبت: (١) الوجهة حيّة، (٢) المسار ذهاباً وإياباً سالك. والأجمل، حقل time=:

text
64 bytes from 8.8.8.8: icmp_seq=1 ttl=63 time=12.9 ms
                       └seq┘ └ttl┘ └── RTT (زمن الذهاب والإياب) ──┘

icmp_seq = رقم تسلسلي (يكشف فقد ردٍّ ما — تذكّر فكرة التسلسل من TCP، أُعيد حقنها هنا في سياقٍ جديد).
time = الـ RTT: الزمن من إطلاق الطلب حتى عودة الرد. هو مقياس صحّة المسار: 7.57ms لـ Google = مسارٌ ممتاز؛ مئات الميلي ثانية = بطءٌ أو ازدحام.

سلبية كاذبة: كثيرٌ من الخوادم وجدران الحماية تُسقِط ICMP عمداً. فقد يكون الجهاز حيّاً تماماً ويخدم الويب، لكن ping يفشل. «لا يرد ping» ≠ «مُطفأ». أنقذتك هذه الخبيئة من ساعاتٍ من التصحيح الخاطئ.
حقل ttl: اشتُقّ من مشكلة «الحزمة الدائرة أبداً» — كل حزمة IP تحمل عدّاداً (Time To Live) يُنقَص واحداً عند كل راوتر؛ إذا بلغ صفراً تُرمى ويُرسَل ICMP Time Exceeded. القيمة الابتدائية شائعة (64 على Linux). فإذا رأيت ttl=63 في ردّ Google فهي تلمّح أن الحزمة عبرت قفزاتٍ من أصلٍ 64. (وهذا ليس دقيقاً تماماً لأن أنظمةً تبدأ من 64 وأخرى من 128/255 — لكنه مؤشّر.)

🔗 سرّ traceroute (وفاءٌ ببذرة المرحلة 02)

كيف يكتشف traceroute كل راوترٍ في الطريق؟ يستغلّ TTL استغلالاً عبقرياً: يرسل حزمةً بـ ttl=1 ← أول راوترٍ يُنقِصها لصفرٍ ويرمي ويُبلّغ بـ ICMP Time Exceeded (فيُفشَى عنوانه!). ثم ttl=2 ← يُفشى الراوتر الثاني. وهكذا حتى تبلغ الوجهة. كل سطرٍ في traceroute = راوترٌ اعترف باسمه لأن حزمتك «ماتت» عنده عمداً.

لاحظ

خبيئة فوق خبيئة: على Linux، traceroute الافتراضي يرسل حزم UDP لمنافذ عالية (لا ICMP echo)، ويعتمد على عودة ICMP Time Exceeded/Port Unreachable. بينما tracert على Windows يستخدم ICMP echo. الوسيلة تختلف، والفكرة (استغلال TTL) واحدة. كل ما تعلّمته يتشابك.

الجزء ب — العناوين الخاصّة: 127.0.0.1 و 0.0.0.0

اللغز

لماذا قد يرسل حاسبٌ حزمةً... لنفسه؟ ولماذا يحتاج خادمٌ أن يقول «استمع على كل عناويني» بدل عنوانٍ محدّد؟ خمّن قبل أن تقرأ.

127.0.0.1 / localhost — الـ Loopback

الـ socket (IP+port) صار الواجهة الكونية لـ«عميلٌ يكلّم خادماً». لكن ماذا لو أردتَ تشغيل العميل والخادم على نفس الجهاز؟ (اختبارٌ محلّي، قاعدة بياناتٍ على نفس الخادم، خدمتان تتكلّمان عبر الشبكة دون أن تغادراه.) تحتاج عنواناً يعني «أنا نفسي».

خُصّص نطاقٌ كامل 127.0.0.0/8 لهذا = loopback. الأشهر 127.0.0.1، واسمه المألوف localhost.
الخبيئة الجوهرية: حزمةٌ لـ 127.x.x.x لا تغادر الجهاز أبداً. لا تصل بطاقة شبكةٍ ولا سلكاً؛ نواة النظام تعكسها (loop back) في البرمجيات. لهذا ping محلّي يكون أسرع ما يكون (microseconds) ويعمل حتى بلا أي شبكة.

إجابة هولبرتون

مفتاح هولبرتون basics_1 task 0: التاسك يطلب أن يُحَل localhost إلى 127.0.0.2 (لا .1). يعمل لأن 127.0.0.2 أيضاً داخل 127.0.0.0/8 ← أيضاً loopback! ولذلك يظلّ ping محلّياً وسريعاً. والأهم: التاسك يثبت لك أن localhost مجرّد اسمٍ يُترجَم لـ IP عبر جدولٍ تستطيع تعديله — وهذا مدخلنا للمرحلة 06.

0.0.0.0 — العنوان الشبح بمعنيين

0.0.0.0 لا يعني «جهازاً ما»؛ معناه يعتمد على السياق:

كعنوان ربطٍ (bind) لخادم: «استمع على كل واجهات/عناوين الجهاز». قارن:

خادمٌ مربوطٌ على 127.0.0.1:5432 ← يصله العملاء المحلّيون فقط (آمن، خاص).
خادمٌ مربوطٌ على 0.0.0.0:5432 ← يصله أي أحدٍ من أي شبكة (مكشوف).

كوجهة/مسار: «الافتراضي/المجهول» (default route).

إجابة هولبرتون

مفتاح هولبرتون basics_0 task 4: في مخرجات netstat سترى *:ssh و *:*. الـ * في عمود Local Address هو 0.0.0.0 (أي «كل الواجهات»)؛ وفي Foreign Address *:* يعني «أي مصدرٍ مقبول». الآن تفهم لماذا خدمةٌ تظهر *:ssh يصلها العالم، بينما 127.0.0.1:631 يصلها جهازك فقط. (هذا أيضاً درسٌ أمنيٌّ حقيقي: أوّل ما يفحص مختبِر الاختراق هو ما المربوط على 0.0.0.0.)

🔗 جسر إلى Bash (لأن تاسك ping سكربت)

تاسك holberton basics_0 task 5 سكربتٌ يأخذ IP كوسيط ويفحصه. يتطلّب لبناتٍ من Bash سنعمّقها في المرحلة 07، لكن إليك السؤال «ليش» لكلٍّ منها لتفكّر فيه الآن:

لماذا نحتاج المعاملات الموضعية ($1 = أول وسيط، $# = عددها)؟ لأن السكربت لا يعرف مسبقاً أي IP يفحص — المستخدم يقرّر وقت التشغيل.
لماذا نفحص $# أو [ -z "$1" ] قبل أن نعمل؟ لأن تشغيله بلا وسيطٍ يجب أن يطبع رسالة الاستخدام Usage: ... لا أن ينهار.
لماذا ping -c 5؟ الراية -c = count؛ بلا تحديدٍ يَطلب ping للأبد.

لا تكتب السكربت الآن — فقط لاحظ أن كل قيدٍ في التاسك هو حلٌّ لمشكلة، تماماً كالطبقات.

جرّب

bash
ping -c 3 8.8.8.8          # لاحظ time و ttl و icmp_seq
ping -c 2 127.0.0.1        # loopback: زمنٌ مجهري، يعمل بلا شبكة
ping -c 2 127.0.0.2        # ما زال loopback! (داخل /8)
traceroute 8.8.8.8         # كل سطر راوترٌ فضحه TTL

(على macOS: ping -c 3 يعمل؛ traceroute موجود. لاحظ صياغة TTL قد تختلف قليلاً.)

لغز الإتقان

توقّع — قبل التشغيل — مخرجات ping 127.0.0.2 مقابل ping 0.0.0.0 مقابل ping <عنوان جهازك الحقيقي من ip addr>. أيّها لا يغادر الجهاز؟ أيّها بلا معنى كهدف ping ولماذا؟ ثم شغّلها وتحقّق من تفسيرك (لا العكس).
خادمٌ يظهر في ss -tln كـ 127.0.0.1:8080. زميلٌ على نفس الـ LAN لا يستطيع بلوغه رغم أن جهازك يصله. اشرح السبب من اشتقاق 0.0.0.0 وحده. ثم: ما السطر الواحد الذي يجب أن يتغيّر ليصله الجميع، وما الخطر الأمني؟
خادمٌ بعيدٌ يخدم موقعاً سليماً، لكن ping إليه يفشل دائماً. هل هو «مُطفأ»؟ اشرح ثلاثة تفسيراتٍ ممكنة، وكيف تفرّق بينها دون ping (تلميح: المرحلة 07 وأدوات L4).
لماذا قيمة ttl في ردّ خادمٍ قريب (نفس المدينة) أعلى عادةً منها في خادمٍ عبر المحيط؟ اربطها بآلية إنقاص TTL عند كل راوتر.

الخلاصة وموقعك على الشجرة

أكملتَ طبقة Network بجناحها الثاني: ICMP (تحكّم/أخطاء) و ping (إثبات الوصول + قياس RTT)، وفهمتَ TTL وسرّ traceroute.
حللتَ لغز 127.0.0.0/8 (loopback) و 0.0.0.0 (wildcard/any) — وربطتهما مباشرةً بثلاث نقاطٍ في مشروعَي هولبرتون (ping، localhost، الـ * في netstat).
لمستَ لماذا تاسك ping سكربتٌ بمعاملاتٍ موضعية — وهي بذرة المرحلة 07.

العقدة المعلّقة الأخيرة في الجذع أ: ظللنا نكتب localhost و facebook.com، والجهاز يفهم أرقاماً فقط. من المترجم؟ والأخطر: قلتُ إن localhost مجرّد اسمٍ في جدولٍ يمكن تعديله. أي جدول؟ وهل أستطيع أن أكذب على جهازي فأجعل facebook.com يشير لأي مكانٍ أريد؟

بذرة

قبل DNS بعقود، كان لكل حاسبٍ ملفٌّ نصيٌّ صغير يربط الأسماء بالعناوين، يُوزَّع باليد. ذلك الملف ما زال حيّاً على كل جهاز Linux، ويُستشار قبل أي خادم أسماء. اسمه /etc/hosts، وهو ساحة مشروع هولبرتون basics_1 task 0 — حيث ستتعلّم أن «حلّ الأسماء» في جوهره كذبةٌ محلّيةٌ تستطيع إعادة كتابتها. هذه المرحلة 06.

← التالي: 06-names.md