ProtectHome بمقابلہ TOTP بیج: VPN لاگ اِن کیوں ناکام ہوتا ہے

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

یہ تین ناکامیوں میں سے کون سی ہے؟

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

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

جب صرف سروس ناکام ہو تو یونٹ کا فائل سسٹم منظر عام مجرم ہوتا ہے۔

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

اختیار A: راز کو گھر سے باہر لے جائیں

جب سروس /home چھپاتی ہے اور آپ وہ تحفظ رکھنا چاہتے ہیں، تو راز کو ایسی جگہ رکھیں جہاں وہ اسے دیکھ سکے۔ ماڈیول secret= راستہ اور فائل کارروائیاں کرنے والا user= اکاؤنٹ قبول کرتا ہے، جس سے مرکزی ذخیرہ بہت سی شناختوں کی خدمت کر سکتا ہے۔

یہ صاف ستھرا اختیار ہے، اور اسی میں سب سے زیادہ احتیاط درکار ہے، کیونکہ مشترکہ ذخیرہ ایک ہی ڈائریکٹری کو ہر اکاؤنٹ کی حفاظتی حد بنا دیتا ہے۔

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

اس پر بھروسہ کرنے سے پہلے تین چیزیں جانچیں: اکاؤنٹ موجود ہے، ماڈیول کا کاری عمل اس میں تبدیل ہو سکتا ہے، اور فائلیں پابند طریقوں کے ساتھ اسی کی ملکیت ہیں۔ user= کے ساتھ ~ یا گھر کے متغیر والا راستہ استعمال نہ کریں، اور راستہ چلانے کے لیے ماڈیول کی ملکیت کی جانچیں بند نہ کریں۔ پاس ورڈ مرحلہ اور باقی اسٹیک کو برقرار رکھیں۔

اختیار B: فائل رہنے دیں اور راستہ کھولیں

اگر راز صارف کے گھر میں ہی رہنا چاہیے، تو یونٹ کو ایسا منظر درکار ہے جو میزبان کے ہر گھر کو بے نقاب کیے بغیر اسی ایک ڈائریکٹری کو شامل کرے۔ drop-in سینڈباکس شدہ گھر کے نیچے تنگ دائرے کا bind ماؤنٹ شامل کر سکتا ہے۔

یہ فی صارف ملکیت کو ماڈل کے طور پر رکھتا ہے، مگر سینڈباکس بدلنے پر نظرِ ثانی طلب یونٹ تبدیلی کی قیمت پر۔

دو حدیں آسانی سے نظر انداز ہو جاتی ہیں۔ سینڈباکس کی چھپائی ہوئی ڈائریکٹری کے نیچے شامل صرف پڑھنے کا راستہ اسے بے نقاب نہیں کرتا، کیونکہ والدین موجود ہی نہیں۔ اور اگر ماڈیول کو حالت تازہ کرنی ہو تو ماؤنٹ لکھنے کے قابل ہونا چاہیے، جو اگلا اختیار سامنے لاتا ہے۔ drop-in کو /usr/lib کے نیچے پیک شدہ یونٹ میں ترمیم کرنے کے بجائے الگ فائل کے طور پر لکھیں، تاکہ پیکج اپ گریڈ اسے خاموشی سے منسوخ نہ کرے۔

اختیار C: سینڈباکس رکھیں اور حالت کی تحریریں درست کریں

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

وہ ناکامی اگلی کوشش میں برے کوڈ کی طرح نظر آتی ہے نہ کہ اس کوشش میں، اسی لیے اسے گھڑی کے انحراف سے غلط سمجھا جاتا ہے۔

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

خود کے طور پر نہیں، سروس کے طور پر تصدیق کریں

ہر اہم جانچ یونٹ کے سینڈباکس کے اندر یونٹ کی شناخت کے ساتھ چلنی چاہیے۔

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

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