VPN تصدیق کے بیک اینڈ کی منتقلی بغیر پرانے ہیش دوبارہ استعمال کرنے کے

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

علامت: اکاؤنٹس موجود ہیں، سیشنز نہیں

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

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

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

کسی کو منتقل کرنے سے پہلے سلسلہ نقش کریں

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

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

ہیش طریقوں کے درمیان سفر نہیں کرتے

اسناد کی مطابقت ایک بار جانچنی چاہیے، کسی بھی گروپ کی منتقلی سے پہلے۔ FreeRADIUS تقسیم کو واضح طور پر بیان کرتا ہے: CHAP جانچ جو سرور خود کرتا ہے اصل پاس ورڈ مانگتی ہے، اور MS-CHAP وہ پاس ورڈ یا موزوں NT مواد قبول کرتا ہے۔ کسی اور مقصد کے لیے بنایا گیا ہیش کسی بھی صورت میں نہیں بیٹھتا، چاہے وہ کتنا مضبوط ہو۔

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

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

پائلٹ گروپ، پھر زندگی کے چکر کی تبدیلیاں

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

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

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

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

واپسی اسناد بحال نہیں کر سکتی

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

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

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