OpenVPN लगइनमा स्ट्याटिक च्यालेन्ज कोड कहाँ जान्छ

क्लाइन्टले पासवर्ड फिल्डपछि दोस्रो बाकस देखाउँछ, तपाईं हार्डवेयर टोकनबाट कोड टाइप गर्नुहुन्छ, र लगइन अझै प्रमाणीकरण त्रुटिसँग असफल हुन्छ। त्यो बाकस अवस्थित छ, अर्थात् प्रोफाइलले त्यो माग्यो। सर्भरले मानलाई बुझ्ने ढाँचामा कहिल्यै प्राप्त गर्यो कि भन्ने अर्को प्रश्न हो, र पहिले त्यसैको उत्तर दिनु उपयुक्त हुन्छ।

तपाईंको क्लाइन्टले वास्तवमा देखाउने प्रम्प्टबाट सुरु गर्नुहोस्

प्रोफाइलमा प्रम्प्ट स्ट्रिङ र टाइप गर्दा जवाफ देखाइने हो कि होइन भन्ने नियन्त्रण गर्ने फ्ल्याग सहितको स्ट्याटिक च्यालेन्ज निर्देश हुन सक्छ। प्रम्प्ट भनेको डायलगमा देखिने कुरा हो; फ्ल्याग त्यही इनपुटको प्रदर्शन प्राथमिकता हो। तीमध्ये कुनैले पनि सर्भरलाई केही कसरी जाँच्ने भनी बताउँदैन।

वास्तवमा तपाईंलाई दिइएका फिल्डहरू गन्नुहोस्। प्रयोगकर्ता नामका लागि एउटा फिल्ड र एउटा मास्क गरिएको फिल्ड भनेको कुनै च्यालेन्ज नभएको सामान्य पासवर्ड लगइन हो। पासवर्डपछि आफ्नै लेबलसहित देखिने दोस्रो फिल्ड भनेको क्लाइन्टले च्यालेन्ज अन्तरक्रिया लागू गरिरहेको हो।

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

सर्भरले पहिले नै के समर्थन गर्नुपर्ने

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

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

यहाँ अपेक्षाहरू पनि क्यालिब्रेट गर्नुपर्छ। दोस्रो प्रम्प्ट इनपुट संयन्त्र हो, दोस्रो कारक लागू हुन्छ भन्ने प्रमाण होइन, किनकि लागू गर्ने काम सर्भरतर्फ हुन्छ र गलत कोड परीक्षण गर्दा मात्र देखिन्छ।

व्यवस्थापन इन्टरफेसले पठाउने इन्कोड गरिएको फिल्ड

जब फ्रन्ट एन्डले व्यवस्थापन इन्टरफेसमार्फत जडान चलाउँछ, पेस गर्नुअघि पासवर्ड र च्यालेन्ज जवाफ एउटै मानमा भरिन्छ। व्यवस्थापन इन्टरफेस सन्दर्भ ले ढाँचा लेख्दछ: एउटा उपसर्ग, त्यसपछि छुट्टै Base64 घटकका रूपमा पासवर्ड र जवाफ।

Base64 एउटा इन्कोडिङ हो, सुरक्षा होइन। यसले फिल्ड पढ्न सक्ने कसैबाट केही लुकाउँदैन, र एकपटकको कोडलाई पुनः प्रयोगयोग्य कुरामा बदल्दैन। भरिएको मान पासवर्डकै जस्तो व्यवहारको योग्य छ: साझा प्रोफाइलबाट बाहिर, कमाण्ड लाइनबाट बाहिर र निदान लगबाट बाहिर।

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

स्ट्याटिक विरुद्ध डाइनामिक: फरक समय

स्ट्याटिक च्यालेन्ज पहिलो प्रमाणपत्र पेस गर्नुअघि नै थाहा हुन्छ, त्यसैले क्लाइन्टले त्यो अग्रिमै माग्न सक्छ। डाइनामिक च्यालेन्ज पछि आउँछ, आदानप्रदान सुरु भइसकेपछि प्रमाणीकरण प्रवाहले त्यो पठाउँछ, र कुराकानीको बीचमा आउने अनुरोध सम्हाल्न सक्ने क्लाइन्ट आवश्यक हुन्छ।

एउटाको समर्थनले अर्को दिँदैन। स्ट्याटिक प्रम्प्ट कन्फिगर गर्ने प्रोफाइल निर्देशले सर्भरले सुरु गरेको च्यालेन्ज लागू गर्दैन, र डाइनामिक अनुरोध सम्हाल्ने फ्रन्ट एन्डले अझै स्ट्याटिक देखाउँदैन। अनुरोध कुन पक्षले सुरु गर्यो भनी पढ्नु तिनलाई छुट्याउने सबैभन्दा छिटो उपाय हो।

रखबार नगरिएको सञ्चालन त्यो ठाउँ हो जहाँ यो इन्टरफेसको होइन, डिजाइनको प्रश्न बन्छ। सञ्चित कोड बुट समयको टिकाउ प्रमाणपत्र होइन, र घण्टौंपछिको पुनःजडानमा नयाँ इनपुट चाहिन्छ, जबसम्म तैनाथीले अपरेटरले जानाजान सक्षम गरेको टोकन व्यवस्था समर्थन गर्दैन।

सफलता र असफलता दुवै जाँच्नुहोस्, डायलग मात्र होइन

परीक्षणका दुवै भाग चलाउनुहोस्। सही प्रमाणपत्र र वैध जवाफ सफल हुनुपर्छ; सही प्रमाणपत्र र जानाजान गलत जवाफ अस्वीकार हुनुपर्छ। यदि दुवै सफल भए, क्लाइन्टले केहीले पनि नजाँच्ने इनपुट सङ्कलन गरिरहेको छ, र डायलगलाई नियन्त्रण ठानिएको छ। त्यो एउटै परीक्षणले कुनै पनि प्रोफाइल समीक्षाभन्दा बढी तैनाथी समात्छ।

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