IKEv2: कुञ्जी नवीकरण बनाम पुनः प्रमाणीकरण — जडान पछि किन टुट्छ

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

बाहिरबाट उस्तै देखिने दुई कार्य

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

पुनः प्रमाणीकरण अझ अगाडि जान्छ: यसले नयाँ प्रमाणित सम्बन्ध स्थापना गर्छ, जसको अर्थ प्रमाणहरू फेरि मूल्याङ्कन गरिन्छ। जे सकियो, रद्द भयो वा निर्देशिकामा बदलियो, त्यो त्यही क्षण देखिन्छ।

कुञ्जी नवीकरणले वास्तवमा के बदल्छ

IKEv2 ले छुट्टाछुट्टै जीवनचक्र भएका दुई प्रकारका संगठन राख्छ। IKE SA ले नियन्त्रण च्यानलको रक्षा गर्छ, र CHILD SA ले वास्तविक ट्राफिकको। एउटा नवीकरण गर्नु क्लाइन्ट फेरि जोड्नुको समानार्थी होइन।

यो विभाजनले परिचित ढाँचा व्याख्या गर्छ: ट्राफिक राम्ररी बग्छ, त्यसपछि एउटा CHILD SA नवीकरण हुन्छ र प्रस्ताव मिल्दैन किनकि कसैले हप्तौं अघि एकातर्फ चरण 2 सम्पादन गरेको थियो। त्यो परिवर्तन नवीकरणले प्रयोग नगरेसम्म त्यहीँ हानिरहित रह्यो।

आयुकालका असमानताहरू पनि त्यसै गरी व्यवहार गर्छन्। कुन पक्ष पहिले आफ्नो सीमामा पुग्छ, त्यसले आदानप्रदान सुरु गर्छ, र अर्कोले त्यो स्वीकार गर्नुपर्छ।

पुनः प्रमाणीकरणले के फेरि मूल्याङ्कन गर्छ

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

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

केही कार्यान्वयनहरूले पुनः प्रमाणीकरणका क्रममा पुरानो र नयाँ अवस्था ओभरल्याप गर्छन्। अरूले छोटो खाडल बनाउँछन्। त्यसैले दुई विक्रेतामा उही सेटिङले फरक प्रयोगकर्ता अनुभव दिन सक्छ। मानकले यही भन्छ भनेर मान्नुको सट्टा व्यवहार परीक्षण गर्नुहोस्।

केही बदल्नु अघि टाइमस्ट्याम्प पढ्नुहोस्

असफलताको क्षणलाई संगठनको अघिल्लो र पछिल्लो अवस्थासँगै रेकर्ड गर्नुहोस्। यदि पुरानो संगठन प्रमाणीकरण आदानप्रदानबिना बदलियो भने, तपाईं नवीकरण सीमामा हुनुहुन्थ्यो। यदि असफलताभन्दा ठीक अघि AUTH आदानप्रदान देखा पर्छ भने, तपाईं पुनः प्रमाणीकरणमा हुनुहुन्थ्यो।

strongSwan ले यसलाई छुट्टै सेटिङका रूपमा देखाउँछ: rekey ले कुञ्जी नवीकरण नियन्त्रण गर्छ, reauth ले नयाँ प्रमाणीकरण हुन्छ कि हुँदैन नियन्त्रण गर्छ, र margin मानहरूले प्रत्येक समाप्तिभन्दा कति अघि सुरु हुन्छ निर्धारण गर्छन्। कुञ्जी नवीकरणको कागजात ले अन्तरक्रिया वर्णन गर्छ, र फोरम पोस्टबाट आयुकाल प्रतिलिपि गर्नु अघि यो पढ्न योग्य छ।

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

असफल भएको कुरा बदल्नुहोस्

प्रमाण अस्वीकृतिका लागि पहिचानको समस्या सुधार्नुपर्छ: प्रमाणपत्र नवीकरण गर्नुहोस्, खाता पुनर्स्थापित गर्नुहोस्, कारक फेरि दर्ता गर्नुहोस्। प्रस्ताव वा आयुकालको असमानताका लागि दुवैतर्फका प्यारामिटर तुलना गर्नुपर्छ।

लक्षणबाट बच्न आयुकाल तान्नु एउटै मात्र विकल्प हो जो सधैं काम गरेको जस्तो देखिन्छ र कहिल्यै काम गर्दैन।

नियन्त्रित नवीकरण परीक्षण गर्नुहोस्

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

सफल प्रारम्भिक लगइनले यीमध्ये केही पनि अभ्यास गर्दैन। त्यसपछिको जीवनचक्र नै यी परिनियोजनहरू साँच्चै टुट्ने ठाउँ हो।