مسارات OpenVPN المدفوعة غير مثبتة: التوقيت أو الصلاحيات أو السياسة

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

تبدو هذه الأسباب متطابقة من الخارج وتحتاج إلى إصلاحات مختلفة. اقرأ سجل العميل عند النقطة التي يُتخذ فيها قرار المسار.

أثبت أن المسار غائب، لا أنه معطوب فقط

ابدأ بإثبات أن المسار غائب بدلًا من كونه معطوبًا. على Linux، يسرد ip route show dev tun0 ما ثبّته العميل على جهاز النفق. على Windows، يعرض route print أو Get-NetRoute الشيء نفسه في شكل جدول.

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

التوقيت: أُضيف المسار قبل وجود الجهاز

يحلل العميل PUSH_REPLY الخاص بالخادم بعد أن تكون قناة التحكم قائمة وبعد أن يكون قد هيّأ الواجهة. عندئذ فقط يلمس جدول التوجيه، مستخدمًا أي آلية توفرها المنصة. يمر Linux عبر netlink؛ ويستخدم Windows واجهة برمجة تحتاج إلى رمز مميز مرفوع الصلاحيات. السكربت أو العميل الذي يضيف المسارات فور قراءة الإعدادات قد يعمل قبل وجود جهاز TUN/TAP، فيرفض النواة الإضافة.

السباق نفسه يفسر لماذا يعمل مسار مكتوب يدويًا بينما لا يعمل المسار التلقائي: بحلول الوقت الذي تكتبه فيه، تكون الواجهة قائمة.

يوجد route-delay لهذه الحالة، ويسمّي route-up سكربتًا يعمل بعد تهيئة الواجهة والمسارات. ضع المسارات التي تعتمد على عنوان النفق في ذلك الخطاف بدلًا من مرحلة مبكرة.

الصلاحيات: من يجوز له تغيير الجدول

يحتاج تغيير جدول التوجيه في Windows إلى رمز مميز مرفوع الصلاحيات. قد تضبط واجهة رسومية بدأها مستخدم عادي عنوان المحول عبر الخدمة وتظل غير قادرة على إضافة مسار. يعرض السجل حينها خطأً من نمط رفض الوصول بدلًا من دفع مفقود.

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

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

السياسة: يمكن التخلص من المسارات المدفوعة عمدًا

يجعل route-nopull العميل يتجاهل المسارات التي يدفعها الخادم، بما في ذلك مسار افتراضي مدفوع، بينما يظل عنوان النفق مقبولًا. تُسقط نفس التوجيهات خيارات DNS وDHCP المدفوعة. هذا العميل ليس معطوبًا؛ إنه يتوقع أسطر مسارات صريحة في إعداده الخاص.

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

الملف الشخصي الذي يبدو نظيفًا في محرر نصوص قد يحمل توجيهًا مضافًا أثناء التشغيل.

قارن قائمة الدفع بالجدول

بعد الاتصال، ضع قائمة الدفع لدى الخادم بجانب جدول العميل. على Linux يكون ذلك ip route show dev tun0؛ وعلى Windows، route print أو Get-NetRoute. إذا كان المسار غائبًا، فأصلح التثبيت أولًا. وإذا كان موجودًا وفشلت حركة المرور، فانتقل إلى سياسة التمرير والجدار الناري.

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