169.254 عبر VPN: العنوان لم يكن قابلاً للتوجيه أبداً
تُسقط الوجهة المحلية للرابط قبل أن تصل إلى النفق، لذا لا تؤدي إضافة المسارات إلا إلى توسيع الفشل. اختر بين إصلاح الشبكة الفرعية والجسر.
تضيف المسار فيرتفع النفق، ومع ذلك يموت الـ ping إلى الجانب الآخر بخسارة كاملة بدلاً من “network unreachable”. هذا الفرق مهم، لأنه يصرف النظر عن جدول التوجيه نحو العنوان نفسه. الوجهة 169.254 محلية للرابط، ونطاق المحلية للرابط ينتهي عند أول قفزة بالتصميم، لا بسبب سوء إعداد.
القرار التالي ضيق ويستحق أن يُتخذ صراحة: إصلاح الشبكة الفرعية على جانب الخادم، أو توسيع مقطع الطبقة 2 ليعود العنوان ذا معنى محلي. وكل ما عدا ذلك، بما في ذلك إضافة مسار أوسع، ليس سوى طريقة لجعل الفشل نفسه ينطبق على مزيد من الوجهات.
العنوان ليس بلا مسار، بل غير قابل للتوجيه
تُعيَّن عناوين IPv4 المحلية للرابط ذاتياً عندما لا يجيب شيء أفضل، ومن هنا سلوك العنونة الخاصة التلقائية في Windows وما يقابله في الأنظمة الأخرى. النطاق مستخدم على كل رابط في الوقت نفسه، وهذا بالضبط سبب نجاحه: يمكن لمضيفين على المقطع نفسه أن يتحدثا دون أي تنسيق.
ولهذه الخاصية نفسها يجب ألا يمرر الموجّه هذه الحزم بين الشبكات. فاستقبال حزمة موجّهة إلى وجهة محلية للرابط وإخراجها من واجهة أخرى يخلق التباساً، لأن “المحلي” عند المرسل و“المحلي” عند المستقبل مكانان مختلفان. ولا يوجد بحث يحسم أيهما قصد المرسل. والتمرير هنا ليس خياراً سياسياً يمكن للمسؤول تفعيله؛ فئة العنوان تستبعده.
لذا فإن بوابة تثبّت 169.254.1.10 كعنوان يمكن الوصول إليه عبر النفق تطلب من النواة فعل شيء يحظره تنسيق العنوان. وتُهمل الحزمة قبل أن تصل إلى المضيف البعيد بوقت طويل، ولا تغيّر أي درجة من تخصيص المسار تلك النتيجة.
لماذا يُظهر النفق مشكلة النطاق
تحمل واجهة TUN حزم IP بين طرفين وليس خلفها مقطع مشترك. لا يوجد بث، ولا ARP للجانب الآخر، ولا اكتشاف جيران يستطيع تحويل وجهة محلية للرابط إلى عنوان طبقة ربط. وحتى لو كان التمرير مسموحاً، فليس للعميل سبيل إلى معرفة أي طرف يجب أن يجيب.
تتطابق الأعراض بدقة بمجرد أن تعرف ما تبحث عنه. المسار موجود في الجدول، ويبلّغ ping بخسارة كاملة بدلاً من شبكة غير قابلة للوصول، ويُظهر جدول الجيران مدخلاً ناقصاً أو فاشلاً للوجهة. والتقاط الحزم على النفق يُظهر الحزمة وهي تغادر، وهذا يدفع الناس إلى النظر في الطرف البعيد بدلاً من فئة العنوان.
في Windows هناك عرض ثانٍ يبدو غير مرتبط وله الجذر نفسه: محوّل تُرك بعنوان محلي للرابط فقط ليس له بوابة صالحة للاستخدام، فيعجز تعريف الشبكة عن تصنيف الاتصال ويستقر ملف جدار الحماية على “عام”. النفق ليس السبب؛ العنوان هو السبب.
احسم القرار بثلاثة أسئلة
يتوقف الاختيار بين إصلاح الشبكة الفرعية وجسر الرابط على ثلاثة شروط، وأي منها يستطيع حسمه قبل أن تفتح ملف إعداد.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
تتوقف معظم الحالات عند السؤال الأول. المضيف الذي يُظهر عنواناً محلياً للرابط يعني عادةً أن DHCP لم يجب، أو أن كابلاً أو VLAN خطأ، أو أن أحدهم كتب العنوان يدوياً. إصلاح ذلك أرخص من أي عمل على النفق، ويزيل المشكلة لكل عميل مستقبلي لا لهذا العميل فقط. كما يترك للموقع نطاق DHCP عاملاً، وهو ما أردته فعلاً.
افحص جانب الخادم قبل أن تفترض أي شيء. شغّل ip addr show وip route على المضيف، وarp -n أو route print -4 على العميل، لترى إن كانت البادئة موجودة أصلاً أم أن مدخلاً قديماً هو الشيء الوحيد الذي يدّعي وجودها.
ما تكلفه الجسور عندما تكون الجواب الصحيح
جسر محوّل فعلي مع محوّل TAP يجعل العميل البعيد جزءاً من نطاق البث المحلي. عندها يعمل البث واكتشاف الجيران، ويعود العنوان المحلي للرابط ذا معنى لأن العميل محلي فعلاً على ذلك الرابط.
التكاليف حقيقية وينبغي ذكرها قبل أن يوافق أحد. حركة البث تعبر النفق، والعميل مكشوف للمقطع المحلي لكل غرض لا للخدمات التي يحتاجها فقط، وعلى الخادم الآن تمرير الإطارات بدلاً من توجيه الحزم. هذه مقايضة معقولة لمنصة مختبر أو جهاز بلا مسار إعداد قابل للتوجيه، وخيار افتراضي سيئ للوصول عن بعد.
عندما تبني الجسر، يلزم النصفان: الجسر على الخادم، ومسار في ملف تعريف العميل يخبره أي الوجهات تقع على الجانب الآخر. الجسر وحده يترك العميل يخمّن، والمسار وحده لا يصلح فئة عنوان.