OpenVPN پروفائل سے key-method ہٹانے سے کچھ نہیں بدلتا

برسوں سے چلنے والا پروفائل اچانک شروع ہونے سے انکار کر دیتا ہے، اور پیغام ایسی ہدایت کا نام لیتا ہے جسے کسی کو شامل کرنا یاد نہیں: key-method۔ اگلا تلاش نتیجہ مطابقت کے لیے key-method 2 شامل کرنے کی تجویز دیتا ہے، جو کسی اور دور کا مشورہ ہے۔ وہ سطر مسترد کرنے والا پارسر موجودہ ہے، اور اس میں ایسا کوئی اختیار ہی نہیں۔ سطر ہٹانے سے آغاز درست ہو جاتا ہے، اور اس میں کچھ نہیں بدلتا کہ دونوں فریق سیشن کو کیسے محفوظ رکھتے ہیں۔

پروفائل میں کیا ہے اور پروٹوکول واقعی کیا کرتا ہے، ان کے درمیان یہی خلا یہاں پورا موضوع ہے، اور یہ ان کئی دوسری ترامیم کی بھی وضاحت کرتا ہے جو لوگ ایک ہی وقت میں کرتے ہیں۔ یہ یہ بھی واضح کرتا ہے کہ وہ ترامیم عموماً ایک ہی بنڈل میں کیوں آتی ہیں۔

علامت پارس خرابی ہے، ہاتھ ملانے کی ناکامی نہیں

کوئی بھی پیکٹ بھیجنے سے پہلے اختیارات پڑھے جاتے ہیں۔ نامعلوم ہدایت والا پروفائل اسی مرحلے پر ناکام ہو جاتا ہے، اس لیے عمل کبھی نیٹ ورک تک نہیں پہنچتا اور کبھی ہاتھ ملانے کی خرابی پیدا نہیں کرتا۔ الفاظ عموماً اختیار اور فائل کی نشاندہی کرتے ہیں، جو اسے وجہ سے منسوب کرنے کے لیے آسان ترین ناکامیوں میں سے ایک بناتا ہے۔ اس میں کوئی پیکٹ، راستہ یا فائر وال شامل نہیں۔

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

اگر پیغام ہدایت کا نام لے تو تشخیص مکمل ہے: فائل میں کچھ ایسا ہے جو یہ بلڈ قبول نہیں کرتا۔ اگر پیغام اس کے بجائے فائل کا راستہ بتائے تو مسئلہ غائب include یا کلید ہے، جو اسی آغاز کے مرحلے کا دوسرا حصہ ہے۔

آپ کو یہ نتیجہ نہیں نکالنا چاہیے کہ کلائنٹ یا سرور کو پرانا پروٹوکول موڈ درکار ہے۔ پارس کی ناکامی آپ کی فائل اور بائنری کے درمیان الفاظ کی لغت کا مسئلہ ہے، اور اس معاملے میں بائنری نے اپنی لغت سے صرف ایک لفظ گرا دیا ہے۔

ہدایت اور ترسیلی شکل دو مختلف چیزیں ہیں

پرانا key-method اختیار چنتا تھا کہ TLS کلید کا تبادلہ کیسے فریم ہو، اور جدید تبادلہ وہ کثیر پیکٹ طریقہ ہے جو یہ اختیار کبھی مانگتا تھا۔ اختیار اس لیے گیا کہ اب وہ کچھ نہیں چنتا تھا؛ جس شکل کا وہ نام لیتا تھا وہی واحد بن گئی۔ اس لیے سطر ہٹانے سے سیشن پہلے جیسی ہی فریمنگ میں رہتا ہے۔ متنی ترمیم اسے کسی بھی سمت بدل نہیں سکتی۔

اسی لیے «طریقہ 2 بحال کرنے» کے لیے پرانی بائنری واپس لانا غلط مرمت ہے۔ یہ پرانے ڈیفالٹس والے پرانے پارسر کے سوا کچھ بحال نہیں کرتا، اور اس کے بعد آنے والی اصلاحات آپ سے چھین لیتا ہے۔ یہی منطق سرٹیفکیٹ کی جانچ یا سائفر کی فہرست کمزور کرنے پر بھی لاگو ہوتی ہے، اس امید پر کہ رابطہ واپس آ جائے گا۔

مفید جانچ ورژن اور پارس شدہ ترتیب ہے، فائل میں لفظ کی موجودگی نہیں:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

کیا ہٹانا ہے، اور کس فائل سے

صرف وہی فائل ترمیم کریں جو چلنے والا عمل واقعی پڑھتا ہے۔ پیکج شدہ نظاموں میں یہ عموماً یونٹ کے بتائے ہوئے کلائنٹ یا سرور ڈائریکٹری میں موجود پروفائل ہوتا ہے، آپ کی ہوم ڈائریکٹری میں حوالے کے لیے رکھی کاپی نہیں۔ تیار کردہ پروفائل ٹیمپلیٹ سے دوبارہ بن سکتا ہے، اس لیے صرف تعینات کاپی میں کیا گیا تبدیلی اگلی پروویژننگ کے بعد واپس آ جائے گا۔

متروک سطر حذف کریں اور اینڈ پوائنٹ، سرٹیفکیٹ، سائفر پالیسی اور کنٹرول چینل کی ترتیبات کو اسی حال میں رہنے دیں۔ یہ عمل کے لیے درکار معاون اختیارات ہیں اور پارس خرابی سے متعلق نہیں۔ اگر اسی پروفائل میں آپ کی ناواقف دیگر ہدایات ہوں تو عمل شروع ہونے تک ان کا گروہ حذف کرنے کے بجائے ہر ایک کو آپ کے چلائے جانے والے ورژن سے ملائیں۔

پھر مطلوبہ مثال شروع کریں اور اس کی آغاز کی آؤٹ پٹ پڑھیں۔ سننے والا موجود ہونے کی صورت میں صاف آغاز ہی اس مرحلے کے مکمل ہونے کی تصدیق ہے؛ اس کے بعد کا کلائنٹ امتحان کسی اور سوال کا جواب دیتا ہے۔

مسترد شدہ پروفائل اور مسترد شدہ کلائنٹ ایک جیسے دکھتے ہیں

دو ناکامیاں یکساں معاونت کے دھاگے پیدا کرتی ہیں اور مختلف شواہد مانگتی ہیں۔ جو سرور اپنی ترتیب خود مسترد کرتا ہے وہ کبھی شروع نہیں ہوتا، اس لیے کوئی کلائنٹ اس سے جڑ نہیں سکتا۔ جو سرور ٹھیک شروع ہو کر ایک کلائنٹ کو مسترد کرتا ہے وہ چل رہا ہے، اور اس کے لاگ میں وجہ موجود ہے: سرٹیفکیٹ کا مسئلہ، دھکیلا گیا اختیار جو کلائنٹ قبول نہیں کرتا، سائفر کا عدم توافق۔

ہٹایا گیا اختیار دوسری صورت کے لیے تشخیص نہیں، اور اس کی طرف ہاتھ بڑھانا وہی گھنٹہ دو بار ضائع کرتا ہے۔ اگر کلائنٹ لاگ سرور کا انکار دکھائے تو وہی انکار پڑھیں؛ اگر مقامی خرابی دکھائے تو جانچنے والی فائل کلائنٹ پروفائل ہے۔ ایسی ہدایت کی طرف ہاتھ بڑھانا جو اب موجود نہیں، دونوں تحقیقات کو یکساں تاخیر دیتا ہے۔

مطابقت کے وہ سوالات جن کا جواب اس سطر نے کبھی نہیں دیا

اس ہدایت کے ساتھ گردش کرنے والے پروفائل عموماً کسی مخصوص پلیٹ فارم کی کہانی ساتھ رکھتے ہیں، اور کہانی تکنیکی وجہ سے زیادہ زندہ رہتی ہے۔ موبائل یا ڈیسک ٹاپ کلائنٹ کو اب بھی مکمل معاون پروفائل کی ضرورت ہے: قابل اعتماد سرٹیفکیٹ زنجیر، دونوں سروں کو قابل قبول ڈیٹا سائفر، دونوں سروں میں نافذ کنٹرول چینل موڈ، اور ایسی کوئی ہدایات نہ ہونا جنہیں کلائنٹ کا بلڈ مسترد کرے۔ ان میں سے کوئی بھی پرانی key-method سطر کی موجودگی یا عدم موجودگی سے طے نہیں ہوتا۔

کمپریشن اسی شکل کا الگ پالیسی سوال ہے۔ key-method سطر ہٹانا اس بارے میں کچھ نہیں کہتا کہ آپ کی تعیناتی میں کمپریشن ہدایت معاون ہے یا قابل قبول، اور دونوں فیصلے خودمختار طور پر کیے جانے چاہئیں۔ کچھ جڑنے تک بیک وقت کئی حفاظتی ترتیبات حذف کرنا ہی وہ راستہ ہے جس سے چلتا ہوا پروفائل غیر واضح پروفائل بن جاتا ہے۔

آپ نے کیا ہٹایا اور کیوں، اس کا مختصر ریکارڈ رکھیں: اختیار، اسے مسترد کرنے والا ورژن، اور وہ کمانڈ جس نے خرابی دکھائی۔ پروفائل کا وارث بننے والے اگلے شخص کو بالکل یہی تین حقائق درکار ہوں گے، اور انہیں ابھی لکھنا بعد میں دوبارہ بنانے سے سستا ہے۔