صحیح VPN پاس ورڈ گمشدہ سرٹیفکیٹ کا متبادل نہیں ہو سکتا

اسناد درست ہیں، پروفائل صاف طور پر درآمد ہوتا ہے، اور تصدیق مکمل ہونے سے پہلے ہی رابطہ ناکام ہو جاتا ہے۔ Windows پر پیغام EAP طریقے کے لیے نہ ملنے والے سرٹیفکیٹ کے بارے میں خرابی 798 ہو سکتا ہے۔ OpenVPN پر کلائنٹ لاگ ایسا TLS مصافحہ دکھاتا ہے جو سرور کو کبھی مطمئن نہیں کرتا۔ دونوں ایک ہی گمشدہ شے بیان کرتے ہیں: کلائنٹ سرٹیفکیٹ جو کلائنٹ کو پیش کرنا تھا۔

پاس ورڈ کسی راز کے علم کا ثبوت ہے؛ سرٹیفکیٹ کسی کلید کی ملکیت کا ثبوت ہے، اور ایک دوسرے کا متبادل نہیں۔

پاس ورڈ کبھی مسئلہ نہیں تھا

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

عمل کرنے سے پہلے پیغام پڑھیں۔ اسناد کا مسترد ہونا، سرٹیفکیٹ کی تلاش کی ناکامی اور TLS مصافحے کی ناکامی تین مختلف نتائج ہیں، اور ان میں سے صرف ایک پاس ورڈ سے متعلق ہے۔

کلائنٹ اسٹور میں کیا ہونا چاہیے

دو اشیاء شامل ہیں۔ کلائنٹ سرٹیفکیٹ VPN کلائنٹ چلانے والے صارف کے لیے اس کی نجی کلید کے ساتھ نصب ہونا چاہیے، اور جاری کرنے والی جڑ قابل اعتماد ہونی چاہیے۔ .cer فائل میں صرف عوامی سرٹیفکیٹ ہوتا ہے، اس لیے یہ اکیلا کچھ تصدیق نہیں کر سکتا۔ Windows سرٹیفکیٹ منیجر میں، کلائنٹ کی شناخت موجودہ صارف کے ذاتی اسٹور میں ہوتی ہے، اور جڑ قابل اعتماد جڑوں کے اسٹور میں۔

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

دو مصنوعات، وہی گمشدہ اسناد

OpenVPN سرور طے شدہ طور پر کلائنٹ سرٹیفکیٹ مانگتے ہیں۔ کلائنٹ میں auth-user-pass شامل کرنا صارف نام اور پاس ورڈ بھیجتا ہے، اور TLS مصافحہ اب بھی سرٹیفکیٹ مانگتا ہے، اس لیے صرف پاس ورڈ verify-client-cert require کے تحت رابطہ مکمل نہیں کر سکتا۔ سرور کو کچھ نہ مانگنے پر سیٹ کیا جا سکتا ہے، جو پاس ورڈ کو کلائنٹ کی واحد اسناد بنا دیتا ہے اور یہ طاقت میں حقیقی کمی ہے۔ auth-user-pass-verify کے پیچھے shell اسکرپٹ اسناد کی تصدیق کر سکتی ہے، اور اس کے لیے اسکرپٹ کے اجرا کا فعال ہونا ضروری ہے، جو اسے مناسب تصدیقی بیک اینڈ سے زیادہ خطرناک ڈیزائن بناتا ہے۔

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

جانچیں بند کر کے گمشدہ سرٹیفکیٹ ٹھیک نہ کریں

لالچ یہ ہے کہ پیغام غائب ہو جائے تو تصدیق میں نرمی کی جائے۔ یہ اس کنٹرول کو ہٹا دیتا ہے جو اپنا کام کر رہا تھا اور ایسا رابطہ چھوڑ دیتا ہے جو اب اپنے دعوے کا ثبوت نہیں دیتا۔ اگر گیٹ وے نے حال ہی میں اپنی جڑ بدلی ہے، پروفائل میں ترمیم کے بجائے کلائنٹ پیکیج دوبارہ ڈاؤن لوڈ کریں، کیونکہ پرانے پیکیج میں اب بھی پچھلی جڑ ہو سکتی ہے۔ اگر پروفائل ایڈیٹر میں سرٹیفکیٹ تصدیق کا اختیار نہیں ہے، تو ممکن ہے نصب شدہ Windows ورژن وہ طریقہ ظاہر نہ کرتا ہو؛ XML ہاتھ سے تبدیل کرنے کے بجائے سسٹم اپ ڈیٹ کریں۔

لکھیں کہ سرٹیفکیٹ کس اسٹور میں تھا، کس صارف نے کلائنٹ چلایا اور نجی کلید موجود تھی یا نہیں۔ یہ تین تقریباً ہر واقعہ کی وضاحت کرتے ہیں۔

پاس ورڈ درست تھا۔ طریقے کو درحقیقت جس اسناد کی ضرورت تھی وہ کہیں اور تھی۔