لماذا يُظهر مسار VPN بلا بوابة في مخرجات ip route
السطر الذي يحمل واجهة بلا بوابة هو مسار مباشر، لا مسار معطوب. اقرأ الوجهة و dev و scope، ثم أكّد ذلك باستخدام ip route get.
غالبًا ما تُقرأ جداول التوجيه على أنها معطوبة كلما ظهر عمود البوابة فارغًا، مع أن السطر يكون في العادة مكتملًا بذاته. لا يظهر الحقل via إلا عندما يسلّم النواة الحزمة إلى عنوان القفزة التالية؛ أما المسار المرتبط بواجهة فيصل إلى وجهاته عبر تحليل طبقة الربط أو عبر قرين من نقطة إلى نقطة بدلًا من ذلك. إن قراءة الأعمدة من اليسار إلى اليمين تخبرك في أي حالة أنت، وينبغي أن تتم هذه القراءة قبل أن يعدّل أي شخص مسارًا افتراضيًا. معظم التذاكر المتعلقة ببوابة مفقودة تنتهي عند هذا التمييز.
اقرأ سطر المسار عمودًا بعمود
يبدأ كل إدخال بالوجهة وطول بادئتها، ثم يضيف معدِّلات بمفردات ثابتة: via، dev، proto، scope، src و metric. سطر مثل 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 كثيف لكنه محدد بالكامل. لا ينقصه شيء، ولا يُستنتج منه أي عنوان موجه.
غياب via هو الجزء المثير للاهتمام. بدون قفزة تالية، تحل النواة الوجهة مباشرة على الواجهة المذكورة، وهذا يعني بالنسبة إلى نفق تسليم الإطار إلى جهاز النفق وترك التغليف يتولى الأمر من هناك. يسجل proto kernel أن الإدخال ثُبّت تلقائيًا عند إسناد عنوان، لا بكتابة مسؤول. يقول scope link إن الوجهة قابلة للوصول على ذلك الرابط دون المرور بموجّه، ويسمي src العنوان الذي ستفضله النواة مصدرًا للحركة المطابقة.
اقرأ الآن مسارًا افتراضيًا بالطريقة نفسها: default via 192.0.2.254 dev eth0 proto static metric 100. هنا يوجد via لأن الحزمة تحتاج فعلًا إلى قفزة تالية، وتلك القفزة يجب أن تكون هي نفسها قابلة للوصول على eth0. السطران ليسا نسختين من شيء واحد؛ بل يجيبان عن سؤالين مختلفين حول إلى أين تذهب الحركة.
شكلان من المسارات يُخلط بينهما
مسار شبكة فرعية للنفق ومسار افتراضي يبدوان متشابهين في لقطة شاشة ويتصرفان تصرفًا مختلفًا تمامًا. استخدم الجدول أدناه كمساعدة قراءة للحقول، ثم أكّد الأرقام الفعلية على الجهاز الذي تصحح أخطاءه بدلًا من الوثوق بعينة من دليل.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
ما لا يستطيع الجدول إخبارك به هو النية. المسار المباشر إلى نطاق خاص عبر نفق تصميم مقصود لتقسيم النفق؛ والشكل نفسه الظاهر على مضيف يُفترض أن يرسل كل شيء عبر VPN هو عَرَض. النية تعيش في الإعداد الذي أنتج الإدخال، لذا انظر إلى الأداة التي ثبّتته قبل أن تستنتج أن النواة أخطأت في شيء.
وبالمثل، فإن غياب البوابة ليس إذنًا باختراع واحدة. إذا كان المسار يحتاج فعلًا إلى قفزة تالية، فيجب أن تكون القفزة التالية قابلة للوصول على الواجهة التي تحملها، وبالنسبة إلى نفق من نقطة إلى نقطة فإن عنوان القرين ليس الشيء نفسه كالعنوان المحلي. إن التعامل مع عنوان النفق المحلي كموجّه إيثرنت طريقة شائعة لإنتاج مسار يبدو صحيحًا ولا يمرر شيئًا.
اسأل النواة أي سطر ستستخدمه فعلًا
قراءة الجدول ليست مثل تنفيذ البحث، لأن النواة تستشير قواعد السياسة وجداول عدة وإدخالات مخزنة قبل أن تجيب. الفعل الذي ينفذ البحث الحقيقي هو ip route get، وهو يطبع المسار الذي ستسلكه حزمة بهذه الخصائص.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0ضع الوجهة التي تهمك فعلًا، ثم أضف from أو iif عندما تكون الحركة مختارة المصدر أو معاد توجيهها، لأن البحث المحلي العادي قد يختار مسارًا مختلفًا عن العميل المعاد توجيهه. تسمي الإجابة الواجهة، وعنوان المصدر المختار، وأي قفزة تالية، وهي المعلومات نفسها التي ستُوجَّه بها الحزمة في تلك اللحظة.
إذا فاجأتك الإجابة، اطبع القواعد قبل تعديل أي شيء: يسردها ip -4 rule show بترتيب الأولوية، وعميل VPN يثبّت جدوله الخاص أو قاعدة لحزم موسومة لن يظهر في الجدول الرئيسي على الإطلاق. وسرد كل الجداول يسد هذه الفجوة.
ip -4 route show table all | grep -E 'tun|default'تحقق من الطبقة الأساسية قبل أن تستبدل المسار الافتراضي
على حزم النفق نفسها أن تصل إلى الطرف البعيد، وهي تفعل ذلك عبر الواجهة الفيزيائية باستخدام المسار الذي كان موجودًا قبل تشغيل VPN. إن استبدال المسار الافتراضي كله دون تثبيت ذلك الطرف يرسل الحزم المغلّفة إلى النفق الذي يُفترض أن تبنيه، فينهار الاتصال. أكّد مسار الطرف أولًا ببحث عن عنوان الطرف وحده.
أبقِ ثلاثة أشياء منفصلة عند إجراء التغيير: مسار الطرف الذي يجب أن يبقى على الواجهة الفيزيائية، والنطاقات الخاصة التي ينبغي أن تدخل النفق، والمسار الافتراضي الذي يقرر كل شيء آخر. فصّلها بهذا الترتيب، وطبّق واحدًا في كل مرة، وأعد تشغيل البحث بعد كل خطوة. لا يثبت ping فاشل بعد ذلك سوى القليل بحد ذاته، لأن الأذونات وتوجيه الردود و DNS والخدمة نفسها كلها تقع في المصب من مسار صحيح.
اكتب القيم الأربع التي أعطاك إياها السطر قبل التعديل: الوجهة، والقفزة التالية أو غيابها، والجهاز، والمصدر المختار. إذا حرّك تغيير لاحق أيًا منها، فأنت تعرف أي قرار قد تغير فعلًا، ويمكنك استعادة إدخال واحد بدلًا من التخمين في الجدول كله.