آیا OpenVPN خط اول را رد می‌کند؟ فایل احتمالاً UTF-16 است

خطا به خط اول یک فایل .ovpn اشاره می‌کند و چیزی شبیه حروف به‌هم‌ریخته را در جایی نقل می‌کند که باید client باشد. فایل در ویرایشگر شما بی‌اشکال باز می‌شود، خط اول client خوانده می‌شود و دستور کاملاً عادی است. هر دو مشاهده درست هستند، چون ویرایشگر بایت‌ها را رمزگشایی می‌کند و کارخواه این کار را نمی‌کند. آنچه می‌بینید تقریباً همیشه یک مشکل رمزگذاری است، نه یک مشکل نحو.

افسانه: ویرایشگر فایل را به شما نشان می‌دهد

ویرایشگر متن بایت‌ها را با رمزگذاری‌ای که یا تشخیص می‌دهد یا حدس می‌زند به نویسه تبدیل می‌کند. وقتی UTF-16 را حدس می‌زند، فایل روی صفحه بی‌عیب به نظر می‌رسد در حالی که بایت‌های زیرین جفت‌اند و پس از هر حرف لاتین یک بایت صفر می‌آید. OpenVPN آن بایت‌ها را به‌عنوان نویسه می‌خواند و ناسازگاری در نخستین دستوری آشکار می‌شود که می‌کوشد تجزیه کند.

پس خط قابل مشاهده و خط تحویل‌شده دو چیز متفاوت‌اند. پاک‌کردن نویسه‌های عجیبی که می‌بینید تغییری در نمایش است نه در رمزگذاری، و تجزیه بعدی به همان دلیل با پیامی کمی متفاوت شکست می‌خورد. به همین دلیل دنبال‌کردن نشانهٔ داخل خطا همیشه بی‌نتیجه می‌ماند. بایت‌ها در مبدأ اشتباه‌اند و هر خوانندهٔ بعدی همان دنبالهٔ خراب را حدس می‌زند.

شکل مشخص این شکست ارزش شناختن دارد، چون به شکلی ویژه تشخیصی است. نشانه‌ای در آغاز فایل، در نمایه‌ای که در ماشین‌های دیگر کار کرده است، پرسشی دربارهٔ ترتیب بایت است نه دربارهٔ واژگان.

بایت‌های نخست واقعاً چه می‌گویند

بایت‌ها را بخوانید نه نویسه‌ها را. دو فرمان کوچک در چند ثانیه آن را روشن می‌کند و هیچ‌کدام نیازی به بازکردن فایل در برنامه‌ای که ممکن است تغییرش دهد ندارد:

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

الگویی که می‌جویید جفتی از بایت‌های آغازین است که متنی با هر بایت دوم صفر در پی آن می‌آید. FF FE نشانهٔ UTF-16 little-endian است، FE FF نشانهٔ big-endian و EF BB BF نشانهٔ UTF-8 با نشان ترتیب بایت. فایل سادهٔ UTF-8 بدون نشان مستقیماً با بایت نخستین حرف آغاز می‌شود.

بایت‌های صفر میان حروف نشانهٔ اصلی است. در UTF-16 little-endian واژهٔ 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 چسبانده‌شده جای بدی برای فایلی هستند که ممکن است کلید خصوصی داشته باشد، چون مشکل رمزگذاری آسان اصلاح می‌شود و کلید لو‌رفته نه.