auth-nocache اور اسناد کی فائل: مدد کرتا ہے یا نقصان دیتا ہے؟

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

اسناد کی درخواست کا جواب دینے کے دو طریقے

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

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

اس موازنے کا باقی حصہ اسی تقسیم سے آتا ہے: ایک ماڈل کے لیے یادداشت کا انتظام، دوسرے کے لیے فائل کا انتظام اور عمل کی شناخت۔

auth-nocache دراصل کیا نکالتا ہے

متعامل لاگ اِن میں، --auth-nocache استعمال کے بعد محفوظ نقل کو یادداشت سے ہٹا دیتا ہے۔ قیمت یہ ہے کہ ہر دوبارہ بات چیت کے وقفے پر نئی درخواست, کیونکہ اگلا دور نکالی گئی چیز کو دوبارہ استعمال نہیں کر سکتا۔

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

اختیار اس لیے شامل کریں کہ آپ یہ تبادلہ سمجھتے ہیں، اس لیے نہیں کہ انتباہ نظر آیا۔ لاگ کو خاموش کرنے کے لیے شامل کیا گیا اختیار وہ اختیار ہے جس کا اثر کسی نے ناپا نہیں۔

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

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

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

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

عملی اصلاحات چمکیلی نہیں ہیں: فائل کو ایسی ڈائریکٹری اور مالک کے پاس لے جائیں جسے ڈیمن کا اکاؤنٹ پڑھ سکے، یا استحقاقی پڑھائی رکھیں اور یقینی بنائیں کہ آپ کا کلائنٹ صرف ایک بار پڑھتا ہے۔ فائل کو سب کے لیے پڑھنے کے قابل بنا کر اسے حل نہ کریں۔

وہ صورت جسے واقعی اختیار چاہیے

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

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

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

ایک فیصلے میں موازنہ

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

کوئی ماڈل محفوظ پاس ورڈ کو اپنے آپ محفوظ نہیں بناتا، اور کوئی آغاز کے انتباہ کو معنی خیز نہیں بناتا۔

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