خطأ OpenVPN: خيار غير معروف tls-remote أو keysize

يبدأ الأمر عادةً بملف تعريف ظل متصلًا لسنوات، ثم يُفتح على عميل أحدث فيفشل قبل أن يبدأ النفق أصلًا. تطبع الطرفية رسالة مثل Options error: Unrecognized option ... in client.ovpn:130: tls-remote، مع إصدار بين قوسين في النهاية. اقرأها كشكوى من المحلل: الملف يحتوي على توجيه لم يعد هذا العميل يعرفه.

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

اقرأ السطر الفاشل قبل تعديل أي شيء

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

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

ماذا حدث لـ keysize و tls-remote

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

أُزيل tls-remote في 2.4. كان يقارن شهادة الخادم باسم متوقّع، وبديله هو verify-x509-name، وهو أكثر صرامة في طريقة مطابقة الاسم. التوجيه القديم اختفى، لذا لن يُحلَّل ملف تعريف يحمله أبدًا على عميل حديث.

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

أعد كتابة فحص هوية الخادم

يأخذ البديل الاسم المتوقّع ووضع مقارنة. verify-x509-name vpn.example.edu name يشترط أن يساوي موضوع الشهادة تلك القيمة تمامًا. تطابق الأوضاع الأخرى بادئة أو سلسلة موضوع كاملة، واختيار الوضع الخطأ يحوّل ملف تعريف عاملًا إلى فشل تحقق نظيف.

إذا كانت وسيطة tls-remote القديمة هي الاسم الشائع الكامل للخادم، فمقارنة name الدقيقة هي الخيار الصحيح عادةً. وإذا كانت قيمة جزئية، فاستخدم وضع البادئة بدلًا من تقصير الاسم المتوقّع، لأن مطابقة دقيقة أقصر لن تتحقق. وعندما لا تكون القيمة الأصلية مكتوبة، فاسأل من يشغّل الخادم عن الموضوع الذي ينشره.

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

ملف تعريف مصحّح أو تعديل محلي أو عميل أقدم

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

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

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

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