MFA سروس بند: VPN رسائی کا فیصلہ پہلے کریں

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

مرحلہ 1: تینوں نتائج کے نام الگ رکھیں

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

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

مرحلہ 2: وہ ناکامی موڈ پڑھیں جو پراکسی واقعی استعمال کرتا ہے

وہ ترتیب تلاش کریں جو سروس سے رابطہ نہ ہو سکنے پر رویے کو کنٹرول کرتی ہے، اور اسے ٹیمپلیٹ سے نہیں، چلتی کنفیگریشن سے پڑھیں۔ Duo کی RADIUS پراکسی میں دستاویز شدہ failmode اقدار safe اور secure ہیں، جہاں safe صرف اسی صورت میں کوشش کی اجازت دیتا ہے جب بنیادی توثیق کامیاب ہو، اور secure اس حالت میں کوشش مسترد کرتا ہے۔

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

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

اگر کوئی نہ بتا سکے کہ کون سا موڈ فعال ہے تو رک جائیں۔ رہنما کا باقی حصہ اسی جواب پر منحصر ہے۔

مرحلہ 3: دوبارہ کوششوں کو بہاؤ سے ہم آہنگ کریں

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

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

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

اگر دو اجزا دونوں دوبارہ کوشش کریں تو پہلے دوبارہ کوششوں کی ملکیت درست کریں۔ دوہری درخواستیں دو مالکان کی علامت ہیں، سست سروس کی نہیں۔

مرحلہ 4: ہنگامی رسائی کو الگ سے سنبھالیں

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

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

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

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