هل يرفض OpenVPN السطر الأول؟ الملف على الأرجح بترميز UTF-16

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

الأسطورة: المحرر يعرض لك الملف

يفك محرر النصوص ترميز البايتات إلى حروف باستخدام ترميز إما يكتشفه أو يخمّنه. عندما يخمّن UTF-16، يبدو الملف مثاليًا على الشاشة بينما البايتات الأساسية أزواج، بعد كل حرف لاتيني بايت صفري. OpenVPN يقرأ تلك البايتات كحروف، ويظهر عدم التطابق عند أول توجيه يحاول تحليله.

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

يستحق شكل الفشل المحدد أن يُعرف، لأنه تشخيصي بطريقة معينة. رمز في بداية الملف تمامًا، في ملف شخصي عمل في حالات أخرى على آلات أخرى، مسألة ترتيب بايتات لا مسألة مفردات.

ما تقوله البايتات الأولى فعلًا

اقرأ البايتات بدل الحروف. أمران صغيران يحسمان الأمر في ثوانٍ، ولا يحتاج أي منهما إلى فتح الملف في تطبيق قد يغيّره:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

النمط الذي تبحث عنه هو زوج من البايتات في البداية يتبعه نص يكون فيه كل بايت ثانٍ صفريًا. يدل FF FE على UTF-16 بترتيب البايتات الصغير، وFE FF على الترتيب الكبير، وEF BB BF على UTF-8 مع علامة ترتيب البايتات. ملف UTF-8 عادي بلا علامة يبدأ مباشرة ببايت الحرف الأول.

البايتات الصفرية بين الحروف هي الدليل. في UTF-16 بترتيب البايتات الصغير تشغل كلمة client اثني عشر بايتًا بدل ستة، لأن كل حرف ASCII يتبعه صفر. هذه البنية ليست شيئًا يستطيع عرض المحرر أن يريك إياه، وليست شيئًا يستطيع حذف بايتين أن يزيله.

هناك فارق دقيق مهم هنا: قارئ إعدادات OpenVPN يتخطى فعلًا علامة ترتيب بايتات UTF-8 في بداية الملف، كما يوضح قارئ إعدادات 2.6. هذا التسامح خاص بتلك العلامة، ولا يفعل شيئًا لملف UTF-16 حروفه محشوة بأصفار. التعامل مع العلامتين كأنهما المشكلة نفسها هو النصف الثاني من الأسطورة.

التحويل حفظ باسم، لا حذف

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

ثم نفّذ تحويل ترميز فعليًا، إما عبر قائمة الترميز الصريحة في المحرر أو بمحوّل يصرّح بترميز الإدخال والإخراج:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

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

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

ما لا يصلحه الترميز المصحّح

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

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

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