ہر ڈیوائس کو لاک آؤٹ کیے بغیر VPN پاس ورڈ تبدیل کریں

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

افسانہ: ایک تبدیلی، ہر جگہ ایک ساتھ

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

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

گردش سے پہلے نقول کی فہرست بنائیں

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

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

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

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

نقول کو ان کے مالکان کے سامنے تولیں۔ جس ڈیوائس کا کوئی دعویٰ نہ کرے وہ ایسی ڈیوائس ہے جسے کوئی اپ ڈیٹ نہیں کرے گا، اور دوبارہ کوشش جاری رکھنے کا سب سے زیادہ امکان اسی کا ہے۔

آپ واقعی کون سا راز گھما رہے ہیں

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

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

محفوظ قدر کو وہیں تبدیل کریں جہاں وہ رہتی ہے

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

پاس ورڈ فائل محفوظ کرنے والے کلائنٹ کو فائل دوبارہ لکھی ہوئی چاہیے، جبکہ پوچھنے والے کلائنٹ کو مکمل سائن ان چاہیے۔ NetworkManager راز کنکشن پروفائل کے اندر رکھتا ہے، اس لیے تبدیلی ٹیکسٹ ایڈیٹر کے بجائے nmcli سے گزرتی ہے:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

اسناد کی فائل پڑھنے والا پروفائل تیسرا معاملہ ہے۔ اس فائل کا مواد تبدیل کریں، اس کی اجازتیں بند رکھیں، اور اس کی طرف اشارہ کرنے والے پروفائل میں ترمیم کے بجائے کلائنٹ دوبارہ لوڈ کریں۔ پروفائل تبدیل نہیں ہوا؛ صرف وہ راز تبدیل ہوا جو وہ پڑھتا ہے۔

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

سیشن اور ٹوکن پاس ورڈ سے زیادہ زندہ رہتے ہیں

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

NIST SP 800-63B میں اسناد کے زندگی کے چکر کی رہنمائی تصدیق کنندگان اور سیشن کو الگ زمروں میں رکھتی ہے، اسی لیے پاس ورڈ کی تبدیلی اور عالمی لاگ آؤٹ الگ الگ کارروائیاں ہیں۔ انہیں دو تکمیلی معیاروں والے دو کام سمجھیں۔ پہلا تب مکمل ہوتا ہے جب نئی قدر کام کرے، اور دوسرا تب جب پرانے سیشن ختم ہو جائیں۔

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