پرانا .ovpn پروفائل Ubuntu 24.04 پر ناکام: کون سی سطریں حذف کریں

پروفائل ڈاؤن لوڈ ہوتا ہے، درآمد ہوتا ہے اور پھر فائل کی 12ویں سطر پر Unrecognized option پیغام کے ساتھ رک جاتا ہے جو keysize کا نام لیتا ہے۔ اکاؤنٹ میں کچھ نہیں بدلا، اور سرور اب بھی دوسرے کلائنٹس قبول کرتا ہے۔ بدلا تو کلائنٹ خود: Ubuntu 24.04 انسٹال کرتا ہے OpenVPN 2.6، جبکہ یہ ایکسپورٹ 2.4 کے لیے لکھا گیا تھا۔ مرمت چند سطروں کے حذف کرنے کا مختصر سلسلہ ہے، اور ترتیب اہم ہے کیونکہ ہر پرانا اختیار اگلے کے پڑھے جانے سے پہلے ہی پارسنگ روک دیتا ہے۔

فائل چھونے سے پہلے خرابی کی سطر پڑھیں

OpenVPN فائل اور وہ سطر بتاتا ہے جہاں پارسنگ رکی، اس لیے ایک بار چلانے میں صرف ایک مسئلہ درست کر سکتے ہیں۔ پروفائل ڈیسک ٹاپ ایپلیٹ کے بجائے ٹرمینل سے شروع کریں، کیونکہ ایپلیٹ عام طور پر stderr نگل جاتا ہے اور سطر نمبر ہی واحد قابلِ بھروسا اشارہ ہوتا ہے جو آپ کو ملتا ہے: sudo openvpn --config /etc/openvpn/client/provider.ovpn۔ اس سطر کو درست کریں، دوبارہ چلائیں، اور توقع رکھیں کہ اگلی ناکامی کسی مختلف اختیار کا نام لے گی۔

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

ناکامی کی تین قسمیں، تین مختلف مرمتیں

پرانی ایکسپورٹس تین قابلِ شناخت طریقوں سے ناکام ہوتی ہیں، اور انہیں ایک ہی مسئلے میں سمیٹنا ہی وہ وجہ ہے کہ لوگ ایسے پیکجز دوبارہ انسٹال کرتے ہیں جو کبھی خراب نہیں تھے۔ پیغام کے الفاظ ہی بتاتے ہیں کہ فائل کھولنے سے پہلے آپ کس قسم میں ہیں۔

• پارسنگ کی خرابیاں فائل اور سطر کا نام لیتی ہیں، اور کوئی بھی ٹریفک بننے سے پہلے رک جاتی ہیں۔
• مذاکرات کی خرابیاں جڑتی ہیں، پھر بتاتی ہیں کہ دونوں سرے مشترکہ سائفر یا قابلِ قبول ڈیٹا چینل پر متفق نہیں ہو سکے۔
• تصدیق کی خرابیاں سب سے دور جاتی ہیں اور سرٹیفکیٹ، صارف یا مسترد شدہ اسناد کا نام لیتی ہیں۔

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

2.6 نے جو اختیارات ہٹائے وہ اسی ترتیب سے حذف کریں

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

پہلے keysize ہٹائیں، کیونکہ اس کا کوئی جدید متبادل نہیں اور اس کی موجودگی عام طور پر ایسے سائفر کی نشاندہی کرتی ہے جسے موجودہ کلائنٹ بہرحال مسترد کرتا ہے۔ پھر ncp-disable ہٹائیں، جو سائفر مذاکرات کو کنٹرول کرتا تھا، 2.5 میں متروک ہوا اور 2.6 میں چلا گیا۔ ns-cert-type server کی جگہ remote-cert-tls server رکھیں، جو معاون جانچ کے ذریعے وہی مقصد بیان کرتا ہے۔2.6 کی تبدیلیوں کی تاریخ باقی حذف کرنے ان کے متبادلوں کے ساتھ فہرست کرتی ہے، اس لیے جو کچھ پارسر اب بھی مسترد کرتا ہے اس کا دستاویزی جواب موجود ہے۔

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

BF-CBC کو صرف محدود متبادل کے طور پر چلتا رکھیں

کچھ فراہم کنندگان اب بھی BF-CBC پر ختم ہوتے ہیں، جس پر OpenVPN 2.6 مدد کے بغیر مذاکرات نہیں کرے گا کیونکہ اس سائفر کا 64 بٹ بلاک ہے۔ تنگ مرمت متبادل فہرست اور OpenSSL legacy فراہم کنندہ ہے، پورے کلائنٹ کو نیچے کرنا نہیں۔

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

پہلی سطر legacy فراہم کنندہ لوڈ کرتی ہے تاکہ OpenSSL وہ سائفر اب بھی بنا سکے، دوسری اسے معاون ساتھیوں کے لیے جدید مذاکرات رکھتی ہے، اور تیسری صرف تب لاگو ہوتی ہے جب سرور کچھ بہتر پیش نہ کرے۔ یہ ٹنل کو جان بوجھ کر کمزور کرنا ہے، اس لیے فائل کے ساتھ لکھیں کہ یہ کیوں موجود ہے۔ متبادل منزل نہیں پل ہے، اس لیے اسی وقت فراہم کنندہ سے دوبارہ بنایا گیا ایکسپورٹ طلب کریں۔

--compat-mode کو ہمہ گیر جواب کے طور پر نہ پکڑیں۔ یہ ایک ساتھ کئی رویے بدلتا ہے، مذاکرات اور دوبارہ مذاکرات کے طے شدہ اقدار سمیت، اس لیے کبھی معلوم نہیں ہوتا کہ کون سی تبدیلی اہم تھی۔ اوپر دی گئی تین واضح سطروں کو ترجیح دیں، کیونکہ ہر ایک اپنا اثر بیان کرتی ہے۔

کلائنٹ اصل میں جو پروفائل لوڈ کرتا ہے اس سے تصدیق کریں

درآمد شدہ کنکشن اکثر سسٹم ڈائریکٹری میں کاپی ہو جاتے ہیں، اس لیے آپ کے ڈاؤن لوڈ فولڈر کی فائل میں ترمیم کچھ بھی نہ بدل سکے۔ چلنے والی نقل تلاش کریں: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn۔ پھر ٹنل شروع کریں اور وہ لاگ سطر پڑھیں جو واقعی منتخب شدہ ڈیٹا چینل سائفر بتاتی ہے۔ متبادل پر ہینڈ شیک مکمل کرنے والا کنکشن بتاتا ہے کہ سرور نے کبھی جدید چیز پیش نہیں کی۔

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

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