OpenVPN ले पछि OTP सत्र बन्द गर्छ: पुनः प्रमाणीकरणलाई के चाहिन्छ

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

समाधान भनेको दोस्रो ह्यान्डसेकले के प्रस्तुत गर्नुपर्ने हो भन्ने निर्णय हो, लामो पुनः प्रयास टाइमर होइन।

ग्राहकको दृष्टिकोणबाट आदानप्रदान हेर्नुहोस्

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

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

auth-gen-token ले दोस्रो प्रश्नको उत्तर कसले दिन्छ भन्ने बदल्छ

विकल्प auth-gen-token ले सर्भरलाई सफल लगइनपछि टोकन जारी गर्न दिन्छ, र पछिका पुनः वार्तालापहरूले पासवर्ड र कोड दोहोर्याउने सट्टा त्यही टोकन प्रस्तुत गर्छन्। निर्देशिकाले यसको आयु र नवीकरण व्यवहार लाई कागजात गर्छ, र टोकनलाई आफ्नै म्याद भएको प्रमाणका रूपमा व्यवहार गर्नुपर्छ। पूर्वनिर्धारित मार्गमा सर्भरले बाह्य पासवर्ड प्रमाणकर्तालाई फेरि नबोलाएर टोकन आफैं प्रमाणित गर्छ।

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

खाताको स्थितिमा के हुन्छ निर्णय गर्नुहोस्

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

धेरै सर्भर भएको तैनाथीमा टोकन हस्ताक्षरको रहस्य साझा हुनुपर्छ, नत्र ग्राहकलाई आफ्नो टोकन प्रमाणित गर्न नसक्ने नोडमा पठाइन सक्छ।

लगइन मात्र होइन, म्याद सकिने र पुनः जडान पनि परीक्षण गर्नुहोस्

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

खाता हटाउने परीक्षण अन्तमा गर्नुहोस्। त्यो अवस्थाले तपाईंले लेखेको नीति लागू हुन्छ कि केवल कागजातमा छ भन्ने बताउँछ।

नवीकरण बन्द गरेर यसलाई सुधार्नु हुँदैन

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

लामो पुनः प्रयास टाइमरले खर्च भइसकेको कोड फेरि मान्य बनाउँदैन। यसले जडान टुट्ने कुरा मात्र ढिलो बनाउँछ र लग पढ्न गाह्रो बनाउँछ।