المسار مرفوض بسبب بتات المضيف؟ اكتشف البادئة المقصودة

يعود سطر المسار لديك مرفوضًا، والنصيحة التي تجدها تقول بتفعيل إعادة توجيه IP. هذان الأمران يقعان في مرحلتين مختلفتين من المشكلة. إعادة التوجيه تحدد ما إذا كان يمكن للمضيف نقل الحزم بين الواجهات؛ وليس لها رأي في ما إذا كانت الوجهة التي كتبتها شبكة صالحة. أصلح البادئة أولًا، لأن إعادة التوجيه لن تنقذ عنوانًا وقناعًا متعارضين.

ما الذي يشكو منه المحلّل فعليًا

الوجهة المكتوبة كعنوان مع قناع يجب أن تصف شبكة، والشبكة تبدأ ببتات مضيف مصفّرة. عندما لا يزال العنوان الذي تقدّمه يحمل قيمة في جزء المضيف، يكون الزوج غير متسق داخليًا: 172.20.130.0 يبدو مرتبًا لأنه ينتهي بصفر، لكن الصفر في الثمانية الرابعة ليس الشيء الوحيد المهم. الثمانية الثالثة هي التي تحمل بتات شاردة هنا.

تتعامل الأدوات مع هذا التعارض بطرق مختلفة. المحلّلات الصارمة ترفض السطر وتذكر بتات المضيف. المحلّلات المتسامحة تقنع العنوان وتثبّت شيئًا لم تطلبه، وهذا أسوأ، لأن الإعداد الآن يوجّه نطاقًا لم تقصده أبدًا. وحدة ipaddress في Python تعرض الخيار مباشرة: تحليل الشبكة الصارم يرفع خطأً، وstrict=False يقنع بتات المضيف. قد يكون عميلك صارمًا أو متسامحًا أو متقلبًا بين الإصدارات، فاقرأ الرسالة بدل الثقة بعادة.

اعمل المثال يدويًا

خذ نفقًا يحتاج إلى الوصول إلى 172.20.130.0 بقناع /20. القناع /20 يستعير أربع بتات من الثمانية الثالثة، لذا تُعدّ تلك الثمانية فقط بخطوات من 16: 0 و16 و32 وهكذا حتى 240. القيمة 130 تقع بين 128 و143، ما يعني أن الشبكة المحيطة تبدأ عند 172.20.128.0، لا عند 172.20.130.0 مع تصفير الثمانية الأخيرة.

مكتوبًا، يمتد النطاق من 172.20.128.0 إلى 172.20.143.255 ويضم 4,096 عنوانًا. إدخال القيم نفسها إلى محلّل غير صارم يظهر الاستبدال الذي كان سيجريه نيابة عنك:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

حدّد الوجهة التي قصدتها فعلًا

السطر المرفوض يخفي عادةً واحدة من ثلاث نوايا، وأنت وحدك من يستطيع الاختيار. إذا كان النفق يحتاج النطاق كله، فاكتب 172.20.128.0/20، عنوان الشبكة القانوني. وإذا كان النفق يحتاج مقطع 130 فقط، فالقناع كان خاطئًا و172.20.130.0/24 هو الصيغة الصادقة. وإذا كانت آلة واحدة هي الهدف، فمسار مضيف IPv4 هو /32 ولا تدخل فيه أي حساب أقنعة.

كل واحد من هذه يصرّح بكمية مختلفة من الحركة، وهذا هو السبب الحقيقي لعدم توسيع القناع حتى تتوقف الشكوى. القناع /16 يقبل السطر في أي مكان تقريبًا ويرسل الحركة نحو وجهات لم تقصد أبدًا توجيهها عبر النفق. اكتب أضيق بادئة تطابق النية، ثم أكّدها مقابل القفزة التالية التي تتوقعها، لا مقابل صمت المحلّل.

لماذا لم تكن إعادة التوجيه هي الحل أبدًا

المسار المرفوض لا يصل أبدًا إلى مسار إعادة التوجيه، لذا فإن تبديل net.ipv4.ip_forward لا يمكن أن يغيّر النتيجة. ذلك الإعداد يهم لاحقًا، عندما يجب على المضيف تمرير الحزم بين الواجهات، وتشغيله قبل أن يكون الجدول صحيحًا لا يغيّر سوى المرحلة التي ستفشل بعدها.

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

تحقّق من المسار المثبّت والطريق الذي يكسبه

بمجرد أن يقبل العميل السطر، انظر فيما ثبّته وأي مسار يختاره النواة لعنوان ممثل داخل النطاق. إذا اختلفت البادئة المثبتة عما كتبته، فقد تصرّف مُطبّع نيابة عنك.

استعلم عن عنوان عضو وعن آخر خارج النطاق، ليكون المقارنة ذات معنى بدل سطر واحد مطمئن:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

يجب أن يقع الاستعلام الثالث خارج النفق إذا كانت بادئتك صحيحة، وحين لا يحدث ذلك، يكون المسار الذي بنيته أوسع مما تظن. سجّل ما كان يُفترض أن تغطيه البادئة قبل أن تلمس الإعداد التالي، لأن مسارًا يُحلّل وطريقًا يعمل يبقيان ملاحظتين منفصلتين.