کیا OpenConnect میں --key-password آپ کے VPN اکاؤنٹ کا پاس ورڈ ہے؟

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

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

دو راز، دو مختلف کام

کرداروں کو فائل تک رسائی اور نیٹ ورک میں داخلے کی اجازت کے طور پر پڑھیں۔ کلید کا پاس ورڈ --sslkey میں بتائی گئی PEM نجی کلید کو ڈکرپٹ کرتا ہے تاکہ TLS کلائنٹ سرٹیفکیٹ پیش کیا جا سکے۔ یہ ڈکرپشن مقامی طور پر، کلائنٹ کے عمل کے اندر ہوتی ہے، اور پاس فریز خود کبھی گیٹ وے تک نہیں جاتا۔ گیٹ وے جو دیکھتا ہے وہ سرٹیفکیٹ اور کلید سے بنایا گیا دستخط ہیں۔ OpenConnect کا مینول --key-password کو --certificate اور --sslkey کے ساتھ رکھتا ہے، اور TPM میں رکھی کلید استعمال کر سکنے والی بلڈز میں وہی اختیار اس کے بجائے اسٹوریج کی روٹ کلید کا پاس ورڈ رکھتا ہے۔

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

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

کلید کا پاس ورڈ واقعی کب ضروری ہے

اختیار کا مطلب صرف اس وقت ہے جب کھولنے کے لیے خفیہ کردہ کلید موجود ہو۔ اگر آپ صارف نام اور پاس ورڈ کے ساتھ اور کلائنٹ سرٹیفکیٹ کے بغیر جڑتے ہیں، تو --key-password کے پاس کام کرنے کے لیے کچھ نہیں، اور اسے شامل کرنے سے کچھ نہیں بدلتا۔ اگر آپ --certificate اور --sslkey کے ساتھ جڑتے ہیں، تو پاس فریز بالکل مانگی جائے گی یا نہیں یہ کلید کی فائل کی اپنی شکل طے کرتی ہے۔

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

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

دونوں رازوں کو شیل کی تاریخ سے باہر رکھیں

کمانڈ لائن دلائل دوسرے مقامی صارفین عمل کی میز کے ذریعے پڑھ سکتے ہیں اور وہ اکثر شیل کی تاریخ، اسکرپٹ اور معاونت کے نقول میں قید ہو جاتے ہیں۔ OpenConnect اکاؤنٹ کا پاس ورڈ معیاری ان پٹ سے --passwd-on-stdin کے ساتھ پڑھ سکتا ہے، اور کلید کا پاس فریز دلیل کے بجائے متعامل اپیل یا ایجنٹ سے آ سکتا ہے۔ کوئی طریقہ راز کو بذات خود محفوظ نہیں کرتا، لیکن دونوں اسے سب سے زیادہ کھلی جگہوں سے دور رکھتے ہیں۔

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

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

مردہ ڈیسک ٹاپ بٹن ایک اور خرابی ہے

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

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

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