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

क्लाइन्टले कुन माग्यो पढ्नुहोस्, किनकि तीनै फरक घडीमा सकिन्छन् र फरक सन्देशसहित असफल हुन्छन्।

पुनः प्रयोग गर्न मिल्ने तीन प्रकारका सामग्री

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

पहिलो रिबुटलाई टिक्छ, दोस्रो सामान्यतया सस्पेन्डलाई टिक्छ, र तेस्रोले नेटवर्क परिवर्तनलाई पटक्कै नटिक्न सक्छ। यिनलाई मिसाउँदा गलत समाधान निस्कन्छ, जस्तै कहिल्यै अस्वीकार नगरिएको पासवर्ड रिसेट गर्नु।

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

MaterialTypical lifetimeWhat invalidates it
Cached passwordUntil changedAccount or password policy change
Session tokenMinutes to hoursExpiry, revocation, reauthentication policy
Tunnel SA or TLS ticketConfigured rekey intervalRekey, network change, peer restart

कुञ्जी नवीकरण पुनः प्रमाणीकरण होइन

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

OpenVPN आफ्नै शब्दावलीमा त्यसै गरी व्यवहार गर्छ: पुनः वार्ताको अन्तरालले डेटा च्यानल ताजा गर्छ, र अर्को जडानमा पूर्ण लगइनबाट बच्न प्रमाणीकरण टोकन क्लाइन्टलाई फर्काउन सकिन्छ। त्यो टोकनको आयु हुन्छ, र सर्भरले यो फेरि स्वीकार्ने हो कि होइन भन्ने निर्णय गर्छ।

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

क्लाइन्टले नयाँ चुनौती पूरा गर्न नसक्दा

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

उपकरण र नेटवर्क संक्रमण पनि नीति मूल्याङ्कन सञ्झ्यालभित्र पर्न सक्छन्, त्यसैले Wi-Fi बाट हटस्पटमा जाने क्रम जसरी भए पनि हुने जाँचसँग मेल खान्छ। त्यो संयोगले कारण टाइमर हुँदा नेटवर्कलाई दोषी देखाउँछ।

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

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

के रिपोर्ट गर्ने, र के बन्द नगर्ने

यदि हातले लगइन सफल हुन्छ र स्वचालित पुनः प्रयोग निरन्तर असफल हुन्छ भने, अपरेटरलाई ठ्याक्कै त्यही भन्नुहोस्। यसले घटकको नाम दिन्छ: पुनः प्रयोगको बाटो, प्रमाण होइन। असफलताको समय, प्रयोग भइरहेको खाता र तपाईंले देखेको सूचनाको प्रकार समावेश गर्नुहोस्।

पुनः जडान शान्त बनाउन दोस्रो कारक बन्द नगर्नुहोस्, प्रमाणपत्र प्रमाणीकरण नछोड्नुहोस् र स्क्रिप्टमा प्रमाणहरू टाँस नगर्नुहोस्। यीमध्ये प्रत्येकले नीति लागू गर्नका लागि रहेको जाँच हटाउँछ, र प्रत्येकले लगइन सूचनालाई घटनामा बदल्छ।

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

सम्बन्धित लेखहरू