ٹوکن موجود ہونے کے باوجود OpenVPN اب بھی نجی کلید کی فائل کیوں مانگتا ہے

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

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

کلائنٹ فائل مانگتا ہے کیونکہ پروفائل ایسا کہتی ہے

ڈیفالٹ پروفائل ایک سرٹیفکیٹ فائل اور ایک نجی کلید کی فائل، یا ایک ہی PKCS#12 بنڈل کی توقع کرتا ہے۔ جب وہ ان پٹ نہ ہوں تو کلائنٹ کے پاس لوڈ کرنے کو کچھ نہیں ہوتا اور غائب فائل کی طرح برتاؤ کرتا ہے، اسی لیے علامت کو غائب طریقہ کار کے بجائے ٹوٹا ہوا راستہ پڑھا جاتا ہے۔ PKCS#11 راستہ ان ان پٹ کو مکمل کرنے کے بجائے بدلتا ہے، لہٰذا جو پروفائل اب بھی کلید کی فائل کا نام دیتی ہے وہ فائل استعمال کرتی رہے گی۔ فائل کے ان پٹ جان بوجھ کر ہٹائیں اور ٹوکن کو دونوں حصے دینے دیں۔

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

ترتیب شدہ شناخت ایک مختلف قدر ہے

سرٹیفکیٹ کی شناخت ایک طویل ترتیب شدہ تار ہے جو دریافت کے عمل سے بنتی ہے، اور یہ لائبریری کا راستہ نہیں، نہ ٹوکن کا PIN اور نہ VPN اکاؤنٹ کا نام۔ اس میں اکثر ایسے حروف ہوتے ہیں جنہیں اقتباس درکار ہوتا ہے، اور اقتباس کے بغیر قدر واضح خرابی کے بغیر کٹ سکتی ہے یا غلط پڑھی جا سکتی ہے۔ ٹوکن کیا ظاہر کرتا ہے اس کی فہرست بنانے کے لیے کلائنٹ کے اپنے شناخت کی دریافت اختیار کو استعمال کریں، پھر مطلوبہ اندراج کو بالکل نقل کریں۔ فہرست میں پہلی شے چننا ہی وہ راستہ ہے جس سے آلہ آخرکار غلط سرٹیفکیٹ پیش کرتا ہے۔

دریافت کا نتیجہ پچھلے سوال کا بھی جواب دیتا ہے: کیا ٹوکن اس فراہم کنندہ کے ذریعے بالکل نظر آتا ہے۔ اگر یہ کچھ بھی فہرست نہ کرے تو مسئلہ VPN کلائنٹ سے اوپر ہے اور مڈل ویئر کا ہے۔

جوڑنے والے عمل کو ٹوکن تک پہنچنا چاہیے

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

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

ٹوکن کس چیز کی جگہ نہیں لیتا

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

اندراج اب بھی جاری کنندہ کے ہاں ہونا چاہیے، اور گیٹ وے کو اب بھی شناخت کی اجازت دینی چاہیے۔

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

ورژن، ماڈیول کی ملکیت، منتخب شدہ عوامی شناخت کنندہ اور صاف کی گئی خرابیاں درج کریں، اور PIN اور اسناد کے بنڈل اس اندراج سے باہر رکھیں۔