OpenVPN लॉगिनमध्ये स्टॅटिक चॅलेंज कोड कुठे जातो
स्टॅटिक चॅलेंज पासवर्डच्या शेजारी दुसरे इनपुट जोडते, आणि त्याला आधार देणारा क्लायंट दोन्ही एका एन्कोडेड फील्डमध्ये भरू शकतो। तुम्ही कोणत्या स्थितीत आहात ते जाणून घ्या।
क्लायंट पासवर्ड फील्डनंतर दुसरे बॉक्स दाखवतो, तुम्ही हार्डवेअर टोकनमधून कोड टाइप करता, आणि लॉगिन तरीही प्रमाणीकरण त्रुटीने अयशस्वी होते। ते बॉक्स अस्तित्वात आहे, म्हणजे प्रोफाइलने ते मागितले। सर्व्हरला मूल्य समजण्याजोग्या स्वरूपात मिळाले का हा वेगळा प्रश्न आहे, आणि आधी त्याचेच उत्तर देणे योग्य आहे।
तुमचा क्लायंट प्रत्यक्षात जो प्रॉम्प्ट दाखवतो त्यापासून सुरुवात करा
प्रोफाइलमध्ये प्रॉम्प्ट स्ट्रिंग आणि टाइप करताना उत्तर दाखवायचे का हे नियंत्रित करणारा फ्लॅग असलेली स्टॅटिक चॅलेंज सूचना असू शकते। प्रॉम्प्ट म्हणजे डायलॉगमध्ये दिसणारे; फ्लॅग म्हणजे त्याच इनपुटसाठीची प्रदर्शन पसंती। यापैकी कोणीही सर्व्हरला काहीही कसे तपासायचे हे सांगत नाही।
प्रत्यक्षात तुम्हाला मिळालेली फील्ड मोजा। वापरकर्तानावासाठी एक फील्ड आणि एक मुखवटा लावलेले फील्ड म्हणजे कोणत्याही चॅलेंजशिवाय सामान्य पासवर्ड लॉगिन। पासवर्डनंतर स्वतःच्या लेबलासह दिसणारे दुसरे फील्ड म्हणजे क्लायंट चॅलेंज परस्परसंवाद राबवत आहे।
तुम्ही वापरत असलेल्या क्लायंटमध्ये दुसरे बॉक्स कधीही दिसत नसेल, तर तो क्लायंट परस्परसंवाद राबवत नसेल, किंवा फक्त मॅनेजमेंट इंटरफेससारख्या वेगळ्या फ्रंट एंडद्वारे राबवत असेल। क्लायंट तपासणे प्रोफाइल पुन्हा लिहिण्यापेक्षा स्वस्त आहे, आणि सहसा विसंगती तिथेच असते।
सर्व्हरने आधीच काय आधार द्यावा
प्रोफाइल सांगते की क्लायंटने काय गोळा करावे। ते सर्व्हरवर तपासणी सुरू करत नाही, आणि संबंधित प्रमाणीकरण एकत्रीकरण नसलेला सर्व्हर फक्त ओळखीचा नसलेला पासवर्ड प्राप्त करेल। म्हणूनच काही तैनाती प्रॉम्प्ट दाखवतात आणि प्रत्येक कोड नाकारतात, आणि म्हणूनच कोणती यंत्रणा तपासणी करते याबद्दल ऑपरेटरचे उत्तर महत्त्वाचे ठरते।
कोणती यंत्रणा तपासणी करते ते ऑपरेटरला विचारा। ती PAM शी बोलणारी प्लगइन, टोकन सेवेविरुद्ध उत्तराची पडताळणी करणारा स्क्रिप्ट हुक, किंवा भरलेल्या मूल्याचे स्वतः विश्लेषण करणारे मॅनेजमेंट-आधारित एकत्रीकरण असू शकते। यापैकी प्रत्येक थोडे वेगळे इनपुट अपेक्षित करते।
इथे अपेक्षा संतुलित करणेही आवश्यक आहे। दुसरा प्रॉम्प्ट ही इनपुट यंत्रणा आहे, दुसरा घटक लागू होतो याचा पुरावा नाही, कारण लागू करणे सर्व्हरच्या बाजूला होते आणि चुकीचा कोड तपासल्यावरच दिसते।
मॅनेजमेंट इंटरफेस पाठवणारे एन्कोडेड फील्ड
जेव्हा फ्रंट एंड मॅनेजमेंट इंटरफेसद्वारे कनेक्शन चालवते, तेव्हा सबमिट करण्यापूर्वी पासवर्ड आणि चॅलेंज उत्तर एकाच मूल्यात भरले जाते। मॅनेजमेंट इंटरफेस संदर्भ स्वरूपाचे दस्तऐवजीकरण करतो: एक उपसर्ग, नंतर स्वतंत्र Base64 घटक म्हणून पासवर्ड आणि उत्तर।
Base64 हे एन्कोडिंग आहे, संरक्षण नाही। ते फील्ड वाचू शकणाऱ्या कोणापासून काहीही लपवत नाही, आणि एकदाच्या कोडला पुन्हा वापरण्यायोग्य गोष्टीत बदलत नाही। भरलेले मूल्य पासवर्डसारख्याच वागणुकीला पात्र आहे: सामायिक प्रोफाइलमधून बाहेर, कमांड लाइनमधून बाहेर आणि निदान लॉगमधून बाहेर।
हे एन्कोडिंग गोंधळाचा सर्वात सामान्य स्रोतही आहे, कारण आता सारखी दिसणारी आणि अदलाबदल न करता येणारी तीन स्वरूपे आहेत। साधी क्रेडेन्शियल फाइल पासवर्ड ठेवते। पासवर्ड आणि कोडचे शब्दशः जोडणे वेगळी स्ट्रिंग ठेवते। मॅनेजमेंट क्लायंटचे भरलेले उत्तर तिसरे ठेवते। फक्त त्रुटी गायब झाली म्हणून फील्ड बदलण्यापूर्वी तुमचा तपासणी मार्ग कोणत्या स्वरूपाची अपेक्षा करतो ते निश्चित करा।
स्टॅटिक विरुद्ध डायनॅमिक: वेगळी वेळ
स्टॅटिक चॅलेंज पहिली क्रेडेन्शियल सबमिट होण्यापूर्वीच माहीत असते, त्यामुळे क्लायंट ते आधीच मागू शकतो। डायनॅमिक चॅलेंज नंतर येते, देवाणघेवाण सुरू झाल्यानंतर प्रमाणीकरण प्रवाह ते पाठवतो, आणि संभाषणाच्या मध्यात येणारी विनंती हाताळू शकणारा क्लायंट त्याला आवश्यक असतो।
एकाचा आधार दुसरे देत नाही। स्टॅटिक प्रॉम्प्ट संरचित करणारी प्रोफाइल सूचना सर्व्हरने सुरू केलेले चॅलेंज राबवत नाही, आणि डायनॅमिक विनंत्या हाताळणारा फ्रंट एंड तरीही स्टॅटिक दाखवत नसेल। विनंती कोणत्या बाजूने सुरू केली हे वाचणे हा त्यांना वेगळे ओळखण्याचा सर्वात जलद मार्ग आहे।
देखरेख नसलेले संचालन ही अशी जागा आहे जिथे हे इंटरफेसचा नाही तर रचनेचा प्रश्न बनते। साठवलेला कोड बूटच्या वेळची टिकाऊ क्रेडेन्शियल नाही, आणि काही तासांनंतरच्या पुनर्जोडणीला नवे इनपुट लागेल, जोपर्यंत तैनाती ऑपरेटरने जाणीवपूर्वक सक्षम केलेली टोकन व्यवस्था आधार देत नाही।
यश आणि अपयश दोन्ही तपासा, फक्त डायलॉग नाही
चाचणीचे दोन्ही अर्धे भाग चालवा। बरोबर क्रेडेन्शियल आणि वैध उत्तर यशस्वी व्हायला हवे; बरोबर क्रेडेन्शियल आणि जाणीवपूर्वक चुकीचे उत्तर नाकारले जायला हवे। दोन्ही यशस्वी झाल्यास, क्लायंट असे इनपुट गोळा करत आहे जे काहीही तपासत नाही, आणि डायलॉगला नियंत्रण समजले गेले आहे। ती एकच चाचणी कोणत्याही प्रोफाइल पुनरावलोकनापेक्षा जास्त तैनाती पकडते।
नंतर पुनर्जोडणीनंतर, नोंदणी न केलेल्या खात्यासह आणि तुमचे वापरकर्ते प्रत्यक्षात चालवत असलेल्या क्लायंटद्वारे कनेक्शन पुन्हा करा। प्रॉम्प्ट दिसणे हे क्लायंटचे वर्तन आहे; चुकीचा कोड नाकारला जाणे म्हणजे सर्व्हर काहीतरी लागू करत आहे।