لماذا يُبقي مسار المضيف /32 نقطة نهاية VPN قابلة للوصول

تفتح جدول التوجيه بعد الاتصال فتجد عنوانًا واحدًا يُوجَّه عبر النفق بينما تبقى الشبكة الفرعية المحيطة به متجهة إلى البوابة المحلية. ذلك الإدخال هو مسار مضيف: عنوان واحد، تُطابقه بادئة من الآحاد كلها. وهو مهم لأن قرارات التوجيه تستخدم أطول بادئة مطابقة، لذا يمكن لـ /32 أن يتجاوز /24 أو المسار الافتراضي دون تغيير أيٍّ منهما. أما إن كان ذلك استثناءً حذرًا أو انقطاعًا مستقبليًا فيعتمد على العنوان الذي يسميه ومن يصونه.

عنوان واحد، إدخال واحد في الجدول

يحمل مسار المضيف IPv4 بادئة /32 ويحمل مسار المضيف IPv6 البادئة /128، ما يعني أن الإدخال يمكن أن يطابق عنوان وجهة واحدًا بالضبط. لا يتحرك أي شيء آخر في الجدول: تبقى الشبكة الفرعية المغطية والمسار الافتراضي حيث كانا. الإدخال الضيق يفوز لذلك العنوان لأن بادئته أطول، لا لأنه أُضيف لاحقًا.

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

اقرأ الإدخال من العميل إلى الخارج

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

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

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

يفشل الإدخال الدائم وإدخال وقت التشغيل بشكل مختلف. يختفي إدخال وقت التشغيل مع الجلسة، بينما يصمد الدائم بعد إعادة التشغيل ويواصل إرسال الحركة إلى بوابة لم تعد موجودة.

استثناء نقطة النهاية وفخ التكرار

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

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

تحقّق من المسار الذي يستخدمه التطبيق فعليًا

نجاح ping إلى اسم المضيف دليل ضعيف عندما يتصل التطبيق بعنوان مختلف أو عائلة مختلفة. تحقّق من المجموعة الدقيقة للعنوان والعائلة والمنفذ والواجهة، من الجهاز الذي يشغّل العميل.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

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

أزل الإدخالات التي لم تعد تقابل وجهة حقيقية ودوّن تلك التي تُبقيها. الإدخال /32 غير المفسَّر لا يمكن تمييزه عن خلل بعد ثلاثة أشهر، وسيحذفه الشخص التالي دون أن يعرف ما كان يعتمد عليه.