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 ডাম্প এমন ফাইলের জন্য খারাপ জায়গা যাতে ব্যক্তিগত কী থাকতে পারে, কারণ এনকোডিং সমস্যা সহজে সারানো যায়, ফাঁস হওয়া কী নয়।