OpenVPN लॉगिन में स्टैटिक चैलेंज कोड कहाँ जाता है

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

उसी प्रॉम्प्ट से शुरू करें जो आपका क्लाइंट वाकई दिखाता है

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

आपको वाकई जो फ़ील्ड मिले उन्हें गिनें। उपयोगकर्ता नाम के लिए एक फ़ील्ड और एक मास्क किया गया फ़ील्ड बिना किसी चैलेंज के सामान्य पासवर्ड लॉगिन है। पासवर्ड के बाद अपने लेबल के साथ दिखने वाला दूसरा फ़ील्ड क्लाइंट द्वारा चैलेंज इंटरैक्शन लागू करना है।

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

सर्वर को पहले से क्या समर्थित करना होगा

प्रोफ़ाइल बताती है कि क्लाइंट को क्या इकट्ठा करना चाहिए। यह सर्वर पर जाँच सक्षम नहीं करती, और संबंधित प्रमाणीकरण एकीकरण के बिना सर्वर को बस ऐसा पासवर्ड मिलेगा जिसे वह पहचानता नहीं। इसीलिए कुछ परिनियोजन प्रॉम्प्ट दिखाते हैं और हर कोड अस्वीकार करते हैं, और इसीलिए कौन-सा तंत्र जाँच करता है इस पर ऑपरेटर का जवाब ही मायने रखता है।

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

यहाँ अपेक्षाओं को संतुलित करना भी जरूरी है। दूसरा प्रॉम्प्ट एक इनपुट तंत्र है, दूसरे कारक के लागू होने का प्रमाण नहीं, क्योंकि लागू होना सर्वर की ओर होता है और केवल गलत कोड जाँचने पर दिखता है।

मैनेजमेंट इंटरफ़ेस जो एन्कोडेड फ़ील्ड भेजता है

जब फ्रंट एंड मैनेजमेंट इंटरफ़ेस के जरिए कनेक्शन चलाता है, तो जमा करने से पहले पासवर्ड और चैलेंज जवाब एक ही मान में भर दिए जाते हैं। मैनेजमेंट इंटरफ़ेस संदर्भ प्रारूप बताता है: एक प्रिफ़िक्स, फिर अलग Base64 घटकों के रूप में पासवर्ड और जवाब।

Base64 एक एन्कोडिंग है, सुरक्षा नहीं। यह फ़ील्ड पढ़ सकने वाले किसी भी व्यक्ति से कुछ नहीं छिपाता, और एक बार के कोड को दोबारा प्रयोग योग्य चीज़ में नहीं बदलता। भरा हुआ मान पासवर्ड जैसा ही व्यवहार योग्य है: साझा प्रोफ़ाइल से बाहर, कमांड लाइन से बाहर और निदान लॉग से बाहर।

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

स्टैटिक बनाम डायनामिक: अलग समय

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

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

बिना निगरानी वाला संचालन वह जगह है जहाँ यह इंटरफ़ेस का नहीं, डिज़ाइन का सवाल बन जाता है। सहेजा गया कोड टिकाऊ बूट-कालीन क्रेडेंशियल नहीं है, और घंटों बाद पुनः कनेक्ट पर ताज़ा इनपुट चाहिए होगा, जब तक परिनियोजन ऐसी टोकन व्यवस्था समर्थित न करे जिसे ऑपरेटर ने जानबूझकर सक्षम किया हो।

सफलता और विफलता दोनों जाँचें, सिर्फ डायलॉग नहीं

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

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