.ovpn फ़ाइल में बदलाव करने से सर्वर पर MFA क्यों चालू नहीं हो सकता

आप प्रोफ़ाइल में auth-user-pass जोड़ते हैं, फिर से कनेक्ट करते हैं, और क्लाइंट उपयोगकर्ता नाम और पासवर्ड मांगता है। लगता है MFA चालू है। फिर आप गलत खाते का कोड डालते हैं, या ऐसा कोड जो दस मिनट पहले समाप्त हो गया, और टनल फिर भी ऊपर आ जाती है। यही लक्षण है: क्लाइंट बदला, सर्वर नहीं। एकबारगी पासवर्ड तभी एक कारक है जब सर्वर पर कोई सत्यापनकर्ता तय करे कि वह उस पहचान के लिए वैध है या नहीं जो उसका दावा करती है।

अनुरोध केवल यह साबित करता है कि क्लाइंट ने मांगा, इससे अधिक नहीं

.ovpn फ़ाइल क्लाइंट पक्ष का दस्तावेज़ है। यह क्लाइंट से कह सकता है कि वह क्रेडेंशियल मांगे, उन्हें कैश करे या कैश करना बंद कर दे। यह किसी उपयोगकर्ता को पंजीकृत नहीं कर सकता, PAM मॉड्यूल स्थापित नहीं कर सकता, या सर्वर से ऐसा दूसरा कारक मांगने पर विवश नहीं कर सकता जिसे वह अभी जाँचता नहीं है।

फ़ोन पर प्रमाणक ऐप स्थापित करने से भी वह संबंध नहीं बनता। Google Authenticator PAM परियोजना OTP सत्यापन का घटक है जो OpenVPN के पीछे बैठ सकता है; यह आयातित प्रोफ़ाइल पर Google खाता लॉगिन चिपकाने का तरीका नहीं है।

पंजीकरण वह हिस्सा है जो प्रोफ़ाइल नहीं कर सकती

TOTP को पंजीकरण सामग्री चाहिए जो प्रमाणक ऐप और उसके सत्यापनकर्ता के बीच साझा हो। फ़ोन पर छह अंक आउटपुट हैं; उनके पीछे का बीज गुप्त है, और वह एक ही पहचान का है।

इसलिए ऑपरेटर को ऐसी पंजीकरण प्रक्रिया चाहिए जो सही बीज को सही VPN पहचान से जोड़े, साथ ही खोए फ़ोन के लिए सत्यापित प्रतिस्थापन मार्ग। उपयोगकर्ताओं को अपने नाम की फ़ाइल अपलोड करने देने से पंजीकरण खाता हड़पने का अवसर बन जाता है, और अपलोड को एन्क्रिप्ट करने से यह नहीं बदलता।

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

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

PAM स्टैक पढ़ें कि वास्तव में क्या आवश्यक है

account required pam_permit.so जैसी पंक्ति खाता पात्रता लागू नहीं करती और कोई कारक नहीं जोड़ती। यह उस PAM खाता-प्रबंधन चरण की अनुमति देती है, जो चरण के बारे में कथन है, आपके उपयोगकर्ताओं के बारे में नहीं।

यही बात अनुमतिपूर्ण पंजीकरण विकल्पों पर भी लागू होती है। बिना पंजीकृत गुप्त वाले उपयोगकर्ताओं को स्वीकार करना जानबूझकर लिया गया रोलआउट निर्णय हो सकता है, लेकिन यह प्रमाण नहीं है कि MFA अनिवार्य है, और इसे समाप्ति तिथि के साथ अस्थायी अपवाद के रूप में लिखा जाना चाहिए।

क्लाइंट की अंतःक्रिया को सर्वर के डिज़ाइन से मिलाएँ

auth-user-pass

यह निर्देश उपयोगकर्ता नाम और पासवर्ड इनपुट मांगता है। यह PAM कॉन्फ़िगर नहीं करता, पंजीकरण रिकॉर्ड नहीं बनाता, और सर्वर को यह नहीं बताता कि पासवर्ड फ़ील्ड में TOTP मान है। सर्वर एकीकरण और क्लाइंट को ऐसी अंतःक्रिया पर सहमत होना चाहिए जिसे परिनियोजन वास्तव में समर्थन देता है: चुनौती, प्रलेखित संयुक्त क्रेडेंशियल प्रारूप, या उत्पाद-विशिष्ट प्रवाह।

केवल इसलिए कि क्लाइंट एक फ़ील्ड दिखाता है, पासवर्ड में कोड न जोड़ें। यह केवल वहीं काम करता है जहाँ सर्वर का प्लगइन ठीक वही प्रारूप अपेक्षित करता है, और हर अन्य जगह यह भ्रमित करने वाले ढंग से विफल होता है।

बीज और QR सामग्री को साझा प्रोफ़ाइल और नियमित नैदानिक लॉग से बाहर रखें। प्रमाणित लॉगिन चैनल पर जमा किया गया कोड नियंत्रित पंजीकरण के दौरान दिए गए बीज जैसी ही वस्तु नहीं है, और सहायता टिकट में दोनों को मिलाना ही वह रास्ता है जिससे रहस्य बाहर निकलते हैं।

पुनःकनेक्शन, टोकन और वह परीक्षण जो मामला तय करता है

पहले सफल लॉगिन के बाद क्या होगा, इसकी योजना बनाएँ। पहले स्वीकार किया गया कोड अगली प्रमाणीकरण पर समाप्त हो सकता है या पुनरावृत्ति के रूप में अस्वीकार हो सकता है। auth-nocache क्रेडेंशियल प्रतिधारण नियंत्रित करता है और MFA स्थापित नहीं करता, और reneg-sec 0 फ़ोरम थ्रेड में कितनी भी बार आए, TOTP समर्थन की परिभाषा नहीं है।

कुछ परिनियोजन प्रारंभिक जाँच के बाद प्रमाणीकरण टोकन जारी करते हैं ताकि पुनःकनेक्शन फिर न माँगें। यह अपनी वैधता विंडो और निरसन कहानी वाला डिज़ाइन निर्णय है, आपको विरासत में मिलने वाला डिफ़ॉल्ट नहीं।

फिर प्रवेश नीति को उस क्लाइंट के साथ परखें जिसे लोग वास्तव में उपयोग करते हैं। सही पासवर्ड, प्रमाणपत्र और वर्तमान कोड वाले पंजीकृत उपयोगकर्ता को कनेक्ट होना चाहिए। गलत कोड, बिना पंजीकरण वाला उपयोगकर्ता और प्रतिबंधित खाता—इनमें से हर एक को विफल होना चाहिए, और कारण सर्वर लॉग में दिखना चाहिए। जब तक आप वे अस्वीकृतियाँ नहीं देखते, आपके पास अनुरोध है, नीति नहीं।