لماذا لن يُصلح إضافة opt-verify خطأ التشفير في OpenVPN

تجد اقتراحًا بإضافة opt-verify، فتضيف السطر، ويبقى خطأ التشفير في مكانه تمامًا. هذه النتيجة متوقعة، لأن الخيار لم يتفاوض قط على تشفير. كان فحصًا لاتساق الخيارات، أُهمل في 2.6 وأُزيل في 2.7، وملف تعريف لا يزال يُحلَّل معه لم يفرض بذلك شيئًا.

من المفيد أن تعرف ما كان السطر يفعله قبل أن تستنتج أنه القطعة الناقصة. يشرح التاريخ أيضًا لماذا لا يمكنه المساعدة الآن.

ما كان الخيار يفرضه سابقًا

يصف دليل 2.6 opt-verify بأنه مهمل ويشرح السلوك السابق: يُسقط الخادم العملاء الذين لا تتطابق خياراتهم المعلنة مع خياراته، بمقارنة أشياء مثل نوع الجهاز وMTU. يعتمد ذلك الفحص أيضًا على بقاء فحص اتساق الخيارات مفعّلًا، لذا لم يكن لدى خادم يعمل بـ disable-occ أصلًا. لاحظ مما تُبنى المقارنة: نص يصف إعداد الطرف الآخر. لا يقول شيئًا عن التشفير الذي ستستخدمه قناة البيانات.

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

ما يفعله 2.7 حين يرى السطر

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

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

أين يكمن الفشل في الواقع

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

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

استبدل القصد، لا السطر فقط

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

لا تستجب لاقتراح قديم بأن جميع التشفيرات معطّلة بتمكين كل خوارزمية تاريخية.

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

الهدف هو قيد مدعوم ومسار مصادق عليه يعمل، لا علم قديم لا يزال يُحلَّل.