OpenVPN auth-nocache: اگلی لاگ اِن پر کیا ہوتا ہے

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

اسناد کا دوسرا مجموعہ کہاں سے آنا چاہیے

OpenVPN auth-nocache کو اُن رازوں پر لاگو کرتا ہے جو auth-user-pass اور askpass جمع کرتے ہیں: استعمال کے بعد عمل انہیں اگلی مصافحے کے لیے رکھنے کے بجائے پھینک دیتا ہے۔ دوبارہ بات چیت ٹائمر پر، بطور ڈیفالٹ گھنٹے میں ایک بار آتی ہے، اس لیے دوسری درخواست پاس ورڈ لکھنے والے کے بہت پہلے جا چکنے کے بعد آتی ہے۔ وہی خلا پوری کہانی ہے۔ کیش آن رہنے پر کلائنٹ کسی سے پوچھے بغیر محفوظ نقل دوبارہ چلاتا ہے؛ بند ہونے پر اسے راز کہیں اور تلاش کرنا ہوتا ہے یا ناکام ہونا پڑتا ہے۔

لہٰذا اُس لمحے راز کہاں سے آ سکتا ہے، ہر جگہ کی فہرست بنائیں، اور ایمانداری سے بتائیں کہ اِن میں سے کون سی میزبان پر موجود ہیں۔ ٹرمینل پر بیٹھا شخص، وہ فائل جسے auth-user-pass یا askpass پڑھ سکتے ہیں، یا سرور کا جاری کردہ سیشن ٹوکن — یہی تین یہاں اہم ہیں۔ اگر اِن میں سے کوئی دستیاب نہ ہو، دوبارہ بات چیت تبدیلی کے ایک گھنٹے بعد ناکام ہوتی ہے، اُس لمحے نہیں جب آپ نے یہ کیا۔

تین شکلیں، ناکامی کے تین مقامات

سامنے شخص والا ڈیسک ٹاپ کلائنٹ ہلکا معاملہ ہے: پرامپٹ واپس آتا ہے، کوئی دوبارہ پاس ورڈ لکھتا ہے، اور قیمت توجہ ہے۔ ٹرمینل کے بغیر OpenVPN چلانے والی سروس، کنٹینر یا روٹر سخت معاملہ ہے، کیونکہ جواب دینے کوئی نہیں اور پہلے خاموش رہنے والا دوبارہ رابطہ اب سرنگ ختم کرتا ہے۔ ہائبرڈ دونوں کے درمیان ہے اور اُس سیشن کے غائب ہونے تک ڈیسک ٹاپ معاملے کی طرح برتاؤ کرتا ہے جو پرامپٹ کا جواب دے سکتا تھا۔ اِنہیں الگ کرنے والی بات GUI کی تنصیب نہیں، بلکہ یہ ہے کہ دوبارہ بات چیت کے وقت اسناد کا ماخذ موجود ہے یا نہیں۔

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

ہدایت یا فلیگ: ایک چنیں اور جانیں کہ کون سا استعمال کیا

پروفائل کے اندر auth-nocache اپنی الگ سطر ہے؛ ایسی کال میں جو پروفائل کا واضح نام لے، یہ اُس کمانڈ لائن کا فلیگ ہے، اور OpenVPN کا دستی دونوں شکلیں درج کرتا ہے۔ دونوں اسناد کو رکھنے کے معاملے میں ایک جیسا کام کرتے ہیں اور کوئی بھی انٹرفیس کی قسم کو نہیں چھوتا یا اُسی لاگ میں موجود غیر متعلق وارننگ کو درست نہیں کرتا۔ فرق استقلال کا ہے: فلیگ صرف اُس رن پر لاگو ہوتا ہے، اس لیے unit فائل یا ریپر اسکرپٹ سے دوبارہ شروع ہونے والی سروس کے پاس یہ نہیں ہوگا جب تک ریپر بھی اسے نہ بھیجے۔

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

فیصلہ کریں کہ کون سی شے اِس ترتیب کی مالک ہے، اسے وہیں بدلیں اور کہیں اور نہیں۔ لیپ ٹاپ پر ترمیم شدہ پروفائل اور اُسے فلیگ سے نظر انداز کرنے والا systemd unit ہی وہ جوڑی ہے جو ری بوٹ کے بعد متضاد رویہ پیدا کرتی ہے۔

اسناد کی فائل راز کو مٹانے کے بجائے منتقل کرتی ہے

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

فائل کو ڈیمن چلانے والے اکاؤنٹ کی ملکیت میں رکھیں، کسی اور کے لیے ناقابلِ قراءت، اور میزبان چھوڑنے والے بیک اپ سے باہر رکھیں۔ OpenVPN کا سرور کی طرف کا auth-gen-token اختیار کامیاب لاگ اِن کے بعد کلائنٹ کو سیشن ٹوکن دیتا ہے، جو اکاؤنٹ کے پاس ورڈ سے زیادہ چھوٹی چیز ہے جسے کھلا چھوڑا جائے۔ بہرحال روٹیشن کا قدم فائل کے پاس لکھیں، کیونکہ فائل عام طور پر اُس شخص سے زیادہ عرصہ زندہ رہتی ہے جس نے اسے بنایا۔

دوبارہ بات چیت کو طول دینا لاگت کو منتقل کرتا ہے، ختم نہیں کرتا

دوسری تجویز reneg-sec بڑھانا ہے، جب تک پرامپٹ نظر انداز کرنے کے قابل نایاب نہ ہو جائے۔ یہ سیشن کی کلید روٹیشن کے شیڈول کو دوبارہ لکھتا ہے اور وہی اسناد کا مسئلہ مزید بعد کے، کم قابلِ پیش گوئی لمحے کی طرف دھکیل دیتا ہے؛ یہ اسناد کا ماخذ پیدا نہیں کرتا۔ جو پالیسی کسی وجہ سے شیڈول کے مطابق کلیدیں تجدید کرتی ہے، اُسے صرف پاس ورڈ لکھنے سے بچنے کے لیے نرم نہیں کرنا چاہیے۔

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

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