متريك مسار OpenVPN: لماذا يخسر المسار المختار مع ذلك

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

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

اقرأ سطر المسار بترتيب الحقول

يقبل عميل OpenVPN 2.6 من المجتمع أربعة حقول في سطر route من نوع IPv4: الشبكة، وقناع الشبكة، والبوابة، ومتريك اختياري. موضع البوابة هو حيث توضع الكلمة المفتاحية الخاصة vpn_gateway. وهي تعني القفزة التالية من جهة VPN لهذا الاتصال، وليست رقم جدول توجيه ولا راوترك الفيزيائي. أخطئ في ذلك ويُقرأ باقي السطر بفهم خاطئ لما يفعله. ويأتي مرجع خيارات الشبكة ليوثّق الحقول الأربعة جميعا.

بالنسبة إلى وجهة خاصة، يمكن أن يقرأ السطر هكذا:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

القيمة 30 الصريحة تنطبق على ذلك المسار، وتبقى 50 هي الافتراضي لكل مسار آخر في الملف الشخصي يحذف الرقم. قراءة السطر من اليسار إلى اليمين تكفي لمعرفة أي قيمة تنطبق وأين.

route-metric افتراضي وليس ترتيبا

route-metric يضبط القيمة الاحتياطية للمسارات التي لا تحمل رقمها الخاص. وهو لا يرفع مسارا فوق أي شيء آخر، ولا يعيد ترتيب المسارات التي ثُبّتت بمتريكات صريحة.

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

إذا أردت أن يفضّل مسار واحد مسارا معينا، فضع الرقم على ذلك المسار. وإذا أردت افتراضيا متسقا عبر ملف شخصي مولّد، فاستخدم route-metric واترك الأسطر الفردية كما هي. خلط الاثنين بلا سبب هو كيف ينتهي ملف شخصي بمسار لا يستطيع أحد تفسيره.

افحص ما ثبّته العميل

بعد اكتمال إعادة الاتصال، اسأل النواة لا الملف الشخصي.

ip route show يسرد المسارات التي أضافها العميل، و ip route get 172.20.5.10 يجيب عن السؤال الأكثر فائدة: أي مسار ستستخدمه هذه الوجهة فعلا، وبأي عنوان مصدر. وإذا كانت الوجهة غائبة عن الجدول، فالعميل لم يثبّتها.

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

لماذا يخسر متريك أصغر مع ذلك

تقارن المتريكات المسارات إلى الوجهة نفسها. وهي لا تجعل بادئة واسعة أكثر تحديدا. عندما يكون redirect-gateway def1 قيد التشغيل، يثبّت العميل 0.0.0.0/1 و 128.0.0.0/1، وهاتان البادئتان تغطيان فضاء IPv4 كله بتحديد أكبر من 0.0.0.0/0. ومتريك بقيمة 1 على المسار الافتراضي لا يتفوق عليهما.

ينطبق المنطق نفسه على أي زوج متداخل. فـ /24 يتغلب على /16 لعنوان داخله بغض النظر عن الأرقام الملحقة، لأن البحث يختار أكثر تطابق تحديدا أولا ثم يقارن المتريكات بين المتساويات فقط.

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

قواعد السياسة تعمل قبل الجدول

على Linux، يحدد ip rule جدول التوجيه الذي يُستشار. تُقيَّم القواعد بترتيب الأولوية، لذا يمكن لجدول أسبق أن يعيد مسارا قبل قراءة الجدول الرئيسي أصلا. ولا يمكن لمتريك داخل main أن يتفوق على تطابق في جدول استُشير أولا.

استخدم ip rule show ثم استعلم الجدول المحدد، مثلا ip route show table 100، لترى ما ستعيده تلك القاعدة. إذا أضاف عميل VPN أو وقت تشغيل حاوية قاعدة ما، فقد تكون الإجابة هناك بدلا من الجدول الذي كنت تقرأه. عنوان المصدر يهم أيضا، لأن القاعدة قد تطابق المصدر فتحل الوجهة نفسها بشكل مختلف لحركة النفق وحركة LAN.

تحقق من الوجهة لا من الترتيب

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

أخرج IPv6 وDNS من هذا الفحص. فهما يُضبطان بتوجيهات مختلفة ويُحلّان بآليات مختلفة، ومسار IPv4 عامل لا يقول شيئا عن أي منهما. غيّر طبقة واحدة في كل مرة وأعد تشغيل الاستعلام.