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

गैर-उत्पादन वातावरण में पूरा मैट्रिक्स जाँचें: प्राथमिक विफलता, जानबूझकर अस्वीकृति, चुनौती की समाप्ति और सेवा की अनुपलब्धता। हर एक के लिए प्रवेश परिणाम और लॉग में लिखा गया कारण दर्ज करें। कॉन्फ़िगर किए गए व्यवहार को खोजने के लिए उत्पादन में रुकावट न बनाएँ, और जिस घटना के लिए आपातकालीन पथ लिखा गया है उसी के दौरान पहली बार उसे न जाँचें। कभी न चलाई गई पुनर्प्राप्ति प्रक्रिया एक दस्तावेज़ है, नियंत्रण नहीं।

गाइड तब समाप्त होता है जब तीनों स्थितियों के नाम रख दिए गए हों, विफलता मोड चल रहे सिस्टम से पढ़ा गया हो, पुनः प्रयासों का एक स्वामी हो और आपातकालीन पहुँच का अपना अनुमोदन और समीक्षा हो। पूर्वानुमेय प्रवर्तन के साथ ज्ञात पुनर्प्राप्ति पथ ही दस्तावेज़ करने योग्य परिणाम है।