جدول التوجيه مقابل البحث الفعلي: إلى أين يتجه مرور VPN

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

الجدول مجموعة مرشحين، لا قرار

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

كل عنوان أعلاه مثال توثيقي. المقصود هو شكل الجواب: الواجهة، وعنوان المصدر المختار، والبوابة، والجدول الذي جاء منه الإدخال. إذا لم يطابق ذلك المخرَج الواجهة التي توقعتها، فقد حددت المشكلة بأمر واحد، ولن يخبرك أي قدر من قراءة الجدول الكامل أي مرشح فاز.

البحث يمر بالقواعد، ثم الجداول

في Linux القرار على مرحلتين. تُقيَّم قواعد السياسة بترتيب الأولوية، وأول قاعدة تطابق تسمي جدولًا لاستشارته؛ ثم يجري ذلك الجدول مطابقة أطول بادئة. يمكن أن تطابق القاعدة المصدر أو الوجهة أو علامة الجدار الناري أو الواجهة أو مزيجًا منها، ولهذا قد يكون تفريغ الجدول الرئيسي دقيقًا تمامًا وغير ذي صلة تمامًا بالحزمة التي تحقق فيها.

ip rule show
ip route show table all | head -40
ip route show table 100

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

لـ IPv6 قواعده وجداوله الخاصة. التصميم الذي يشغل العائلتين يحتاج البحثين، وجواب IPv4 العامل لا يقول شيئًا عن مسار v6 الذي قد يفضله عميل ثنائي المكدس.

ما يثبته عميل VPN

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

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

المسار الخارجي يجب أن يصمد أيضًا

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

افحص عنوان القرين كما فحصت الوجهة الداخلية، وتأكد من أنه يحل إلى الواجهة الفيزيائية لا إلى النفق:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

ما لا يستطيع مخرَج التوجيه إخبارك به

البحث الصحيح يعني أن النواة سترسل الحزمة إلى مكان معقول. لا يعني أن الجدار الناري يسمح بها، أو أن سياسة IPsec تغطيها، أو أن قاعدة NAT تترجمها، أو أن الطرف البعيد لديه مسار عودة. كل ذلك مرحلة لاحقة، و ملاحظات strongSwan عن إعادة التوجيه تصف السلسلة التي يتعين على الحزمة اجتيازها على الطرفين.

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

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