AES-256-GCM نہیں ملا: کلائنٹ کی صلاحیت یا گفت و شنید؟
OpenVPN کی دو غلطیاں ایک جیسی لگتی ہیں: الگورتھم کے بغیر بلڈ اور مشترکہ سائفر کے بغیر فریق۔ پروفائل بدلنے سے پہلے --show-ciphers اور data-ciphers پڑھیں۔
کہیں اور چلنے والا OpenVPN پروفائل بتاتا ہے کہ AES-256-GCM نہیں ملا، یا فریقوں کے پاس کوئی مشترکہ سائفر نہیں، اور پہلا خیال پروفائل میں ترمیم کرنا ہوتا ہے۔ یہ دونوں پیغام مختلف ناکامیوں کو بیان کرتے ہیں۔ ایک کہتا ہے کہ مقامی پروگرام میں ایسا الگورتھم نہیں؛ دوسرا کہتا ہے کہ دونوں طرف الگورتھم موجود ہیں مگر مشترکہ انتخاب نہیں۔ کون سی ہے یہ جاننے تک پروفائل میں ترمیم کسی کو درست نہیں کرتی۔
غلطی کا عین متن اور وہ پروگرام پڑھیں جس نے اسے پیدا کیا۔
طے کریں کہ آپ کو کون سی غلطی ہے
نہ ملنے والے سائفر کا پیغام مقامی مشین پر کسی بھی پیکٹ بھیجنے سے پہلے اختیارات کے تجزیے سے آتا ہے۔ یعنی آپ کے سامنے موجود قابل عمل فائل یا وہ لائبریری جس سے یہ منسلک ہے، وہ الگورتھم فراہم نہیں کرتی۔ مشترکہ سائفر نہ ہونے کا پیغام بعد میں، گفت و شنید کے دوران آتا ہے، اور اس کا مطلب ہے کہ دونوں فریق سائفر کی حمایت کرتے ہیں مگر ایک پر متفق نہیں ہو سکتے۔
فرق اہم ہے کیونکہ ایک سافٹ ویئر ورژن کا مسئلہ ہے اور دوسرا کنفیگریشن کا۔ پہلا ورژن نمبر سے طے ہوتا ہے۔ دوسرا دو فہرستوں کے موازنے سے طے ہوتا ہے۔
مقامی صلاحیت کی کمی
پرانی کمیونٹی بلڈز جدید ڈیفالٹ سے پہلے کی ہیں، اور ڈیسک ٹاپ ایپ اپنا انجن لا سکتی ہے جو ساتھ نصب کمانڈ لائن پیکج سے مختلف ہے۔ جانچ اسی قابل عمل فائل پر کریں جس نے واقعی کنکشن شروع کیا، پھر پرانے پروگرام کو نیا الگورتھم سکھانے کے بجائے معاون بلڈ منتخب کریں۔
openvpn --version openvpn --show-ciphers | grep -i gcm openvpn --show-tls | head -5
اگر اس فہرست میں AES-256-GCM نہیں ہے تو کوئی پروفائل سطر اسے شامل نہیں کرے گی۔ حل نیا کلائنٹ یا دوسرا بلڈ ہے، اور پرانے فریق کی پابندیاں الگ ڈیزائن سوال بن جاتی ہیں۔
OpenVPN 3 پر مبنی کلائنٹس میں انجن اور قابل قبول ہدایات کمیونٹی کی 2.x لائن سے مختلف ہیں، اس لیے وہی پروفائل متن ایسی وجوہ سے ناکام ہو سکتا ہے جن کا سائفر فہرست سے کوئی تعلق نہیں۔
گفت و شنید کی کمی
جب دونوں فریق الگورتھم کی فہرست دیتے ہیں تو باقی سوال یہ ہے کہ کون سا فریق کون سی فہرست پیش کرتا ہے۔ کمیونٹی OpenVPN نے گفت و شنید کی ہدایت کا نام بدلا: 2.4 میں ncp-ciphers 2.5 میں data-ciphers بن گیا، اور 2.6 میں پرانی cipher سطر زیادہ تر مطابقت اور واپسی کے لیے کام کرتی ہے، طے شدہ مجموعہ متعین کرنے کے لیے نہیں۔
اسی لیے صرف پرانی cipher سطر بدلنے سے گفت و شنید کی فہرست غیر متاثر رہ سکتی ہے۔ پرانی سطر واپسی کے لیے اب بھی اہم ہے، اور یہ الگ کام ہے۔ دونوں کو ملانا ایسی ترامیم پیدا کرتا ہے جو نظر آنے میں کچھ نہیں بدلتیں۔
openvpn --version | head -2 grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn
دونوں سروں کی فہرستیں اور سرور کا انکار پیغام موازنہ کریں۔ اگر تقاطع خالی ہے تو دوسرے ورژن کے لیے لکھے مضمون سے قدر نقل کرنے کے بجائے فہرستیں جان بوجھ کر ہم آہنگ کریں۔ بہت کشادہ فہرست ہر کنکشن کو خاموشی سے کمزور کرتی ہے۔ بہت تنگ فہرست اس فریق کو خارج کرتی ہے جسے آپ رکھنا چاہتے تھے۔
مطابقت واضح رکھیں
ایک پرانے فریق کے لیے واپسی لاگت والا فیصلہ ہے: ایک ڈیوائس کے جڑنے کے لیے پوری تعیناتی کمزور اختیار قبول کرتی ہے۔ اسے اسی طرح لکھیں، اور صرف اسی فریق تک محدود رکھیں جسے ضرورت ہے۔
دو شرطیں نتیجہ طے کرتی ہیں۔ اگر غلطی مقامی ہے تو بلڈ بدلیں۔ اگر غلطی گفت و شنید کی ہے تو دونوں سروں پر فہرستیں ہم آہنگ کریں اور لکھیں کہ کون سے ورژن معاون ہیں۔
پھر ورژن اور صلاحیت کا آؤٹ پٹ منسلک کر کے عین غلطی کی اطلاع دیں۔ یہ جوڑی غیر موجود الگورتھم کو اختلاف سے الگ کرتی ہے، اور اگلے قیاسی ترمیمی دور کو شروع ہونے سے پہلے روک دیتی ہے۔