OpenVPN बाद में OTP सत्र गिरा देता है: पुनः प्रमाणीकरण को क्या चाहिए

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

समाधान यह तय करना है कि दूसरे हैंडशेक को क्या प्रस्तुत करना चाहिए, लंबा पुनः प्रयास टाइमर नहीं।

क्लाइंट के दृष्टिकोण से आदान-प्रदान का पालन करें

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

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

auth-gen-token बदलता है कि दूसरे प्रश्न का उत्तर कौन देता है

auth-gen-token विकल्प सर्वर को सफल लॉगिन के बाद टोकन जारी करने देता है, और बाद की पुनः बातचीतें पासवर्ड और कोड दोहराने के बजाय वही टोकन प्रस्तुत करती हैं। मैनुअल इसके जीवनकाल और नवीनीकरण व्यवहार का दस्तावेज़ीकरण करता है, और टोकन को अपनी समाप्ति वाले क्रेडेंशियल के रूप में माना जाना चाहिए। डिफ़ॉल्ट मार्ग में सर्वर बाहरी पासवर्ड प्रमाणकर्ता को फिर से कॉल करने के बजाय टोकन स्वयं सत्यापित करता है।

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

तय करें कि खाता स्थिति का क्या होगा

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

बहु-सर्वर परिनियोजन में टोकन हस्ताक्षर रहस्य साझा करना होगा, अन्यथा क्लाइंट ऐसे नोड पर भेजा जा सकता है जो उसका टोकन सत्यापित नहीं कर सकता।

केवल लॉगिन नहीं, समाप्ति और पुनः कनेक्शन भी जांचें

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

खाता हटाने का परीक्षण सबसे अंत में करें। वह स्थिति बताती है कि आपने जो नीति लिखी है वह लागू होती है या केवल दस्तावेज़ीकृत है।

नवीनीकरण बंद करके इसे ठीक न करें

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

लंबा पुनः प्रयास टाइमर खर्च किए गए कोड को दोबारा वैध नहीं बनाता। यह केवल डिस्कनेक्ट में देरी करता है और लॉग पढ़ना कठिन बनाता है।