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

قرر من يملك جدول المسارات

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

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

OwnerWhere it livesResult
Serverserver config, redirect-gateway, pushed routesclient becomes a full tunnel
Profileroute-nopull and its own route linestunnel up, office prefix missing
Managernever-default plus its own routesdesktop decides, profile ignored

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

route-nopull يرشح الدفعات، ولا يضيف مسارات

route-nopull ينتمي إلى ملف تعريف العميل، وترتيبه في ذلك الملف لا يهم لأنه يتجاهل فقط القيم القادمة من الخادم. إنه يتجاهل المسارات المدفوعة، بما في ذلك المسار الافتراضي المدفوع، بينما يظل النفق يعمل بشكل طبيعي.

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

وهذا يترك نفقًا بلا مسار إلى بادئة المكتب ما لم تضف واحدًا بنفسك: route-nopull يتبعه route 10.30.0.0 255.255.0.0 في الملف نفسه. ذلك السطر يحمل عنوانًا وقناعًا؛ ولا يسمي قفزة تالية.

هناك صيغة بديلة تضيف رمز بوابة، route 10.30.0.0 255.255.0.0 vpn_gateway، يوجه الإدخال إلى النفق بالاسم. تختلف أدوات الاستيراد في ما إذا كانت تترجم ذلك المتغير، لذا افحص الاتصال المخزن إذا كان الإدخال مفقودًا من جدول النواة.

تحقق من عمليات البحث عن المسار، لا من ping

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

اقرأ ما ثبته النفق بـ ip route show dev tun0. لا مخرجات على الإطلاق تعني صفر مسارات، وهذا ليس نفقًا منفصلًا يعمل، وهو النتيجة المعتادة لإضافة المرشح دون السطر الصريح.

ثم تحقق من عنوان مكتب واحد بـ ip route get 10.30.5.7، وعنوان إنترنت عادي بـ ip route get 1.1.1.1. يجب أن يسمي الثاني الواجهة الفيزيائية؛ وإذا سمى النفق، فلم يُرشح الدفع إطلاقًا.

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

الشبكات الفرعية المتداخلة تبدو كنفق معطوب

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

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

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

اجعل القرار ينجو من إعادة الاتصال

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

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

مقالات ذات صلة