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 ڈمپ ایسی فائل کے لیے خراب جگہ ہیں جس میں نجی کلید ہو سکتی ہے، کیونکہ انکوڈنگ کا مسئلہ آسانی سے درست ہو جاتا ہے، لیک ہوئی کلید نہیں۔