لماذا توقف OpenVPN عن الاتصال بعد ترقية Ubuntu؟

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

أي طبقة فشلت: المصافحة أم التشفير أم الحزمة أم المكتبة

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

شكاوى الشهادات والتوقيعات، أو رسالة عن طول المفتاح، تأتي من قناة التحكم وسياسة المكتبة التي تحكمها. أما التحذير الذي يبدأ بـ DEPRECATED OPTION فينتمي بدلًا من ذلك إلى تفاوض قناة البيانات.

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

حين تفشل المصافحة، تكون سياسة TLS هي التي ترفض الشهادة

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

الإصلاح الضيق يربط سلسلة تشفير بهذا الاتصال وحده. في محرر سطح المكتب، افتح الملف الشخصي، وانتقل إلى الإعدادات المتقدمة، وضع DEFAULT:@SECLEVEL=0 في حقل تشفير TLS. وملف مفاتيح NetworkManager يأخذ القيمة نفسها تحت [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

أعد تشغيل NetworkManager واتصل من جديد، لأن الخدمة تخزّن الملفات الشخصية المحللة وإلا فستظل تستخدم النسخة التي بحوزتها. اعرف ما يفعله السطر قبل أن تتخذه: ذلك الإعداد حدٌّ عبر عدة معاملات للشهادات والمفاتيح وليس اسم تشفير، فخفضه يوسّع ما يقبله الملف الشخصي الواحد. سجّل أي خادم طلب ذلك وأسقط الإعداد حين يعيد المشغّل إصدار مادة حديثة. أما تغيير /etc/ssl/openssl.cnf فيبلغ الحد نفسه لكل برنامج يقرأ ذلك الملف، وهو أبعد بكثير من VPN.

يحتاج OpenVPN 2.6 إلى التشفير مدرجًا للتفاوض

شحن Ubuntu 22.10 الإصدار OpenVPN 2.6، وفي ذلك الإصدار يتوقف --cipher عن اختيار قناة البيانات بمفرده. ويجب أن يكون التشفير حاضرًا أيضًا في قائمة data-ciphers المتفاوض عليها، وإلا طبع العميل تحذيرًا بإهمال الخيار ثم فشل في رفع النفق.

ملحق NetworkManager من الفترة نفسها كان لا يزال يكتب التوجيه القديم وحده. تلك التفصيلة تقسّم التشخيص، لأن ملفًا شخصيًا صُحح يدويًا قد يتصل من صدفة ويظل يفشل من تطبيق سطح المكتب. أضف القائمة إلى ملف الاتصال تحت [vpn]:

data-ciphers=AES-256-CBC

استخدم القيمة التي يعلنها الخادم لا التي تتذكرها؛ فالخادم الذي يدفع AES-256-GCM لن يتفاوض مع قائمة عميل تذكر CBC فقط. أعد تشغيل المدير واتصل من جديد، ثم كرر المحاولة من صدفة مع تمرير التشفير صراحةً للتفاوض والاحتياط معًا:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

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

أعطال الحزم والملحقات تبدو كأعطال VPN

ليست كل حالات الفشل بعد الترقية تشفيرية. مستودع OpenVPN مضاف تحت اسم إصدار لا يستخدمه الإصدار ينتج حزمة لا تُثبّت أبدًا، فقارن ما lsb_release -a يبلّغ عنه بملف القائمة الذي أضفته. وعنصر universe المفقود أو جيب الأمان ينتج حزمة لا يمكن العثور عليها إطلاقًا. والحالتان تتركان الملف الشخصي سليمًا والنفق مستحيلًا.

اقرأ خطأ مدير الحزم قبل سجل VPN. إذا لم يُثبّت العميل قط، فلن ينتج أي قدر من تحرير الملف الشخصي مصافحة.

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

قد تختبئ مكتبة مورّد خلف خطأ سياسة

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

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

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

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

تثبيت عميل أقدم يشتري وقتًا، لا حلًا

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

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

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