IKEv2: कुंजी नवीनीकरण बनाम पुनः प्रमाणीकरण — कनेक्शन बाद में क्यों टूटता है

सुरंग सुबह उठती है और घंटों काम करती है। फिर वह गिर जाती है, एक पुनः प्रयास के बाद फिर जुड़ जाती है और अगले दिन वही करती है। नेटवर्क पर कुछ नहीं बदला और किसी ने पासवर्ड को नहीं छुआ। नवीनीकरण सीमा पर विफल होने वाले सत्र सामान्यतः दो अलग-अलग कार्यों में से एक को पार करते हैं, और उनमें से केवल एक ही आपके क्रेडेंशियल फिर से जाँचता है। कौन-सा सक्रिय हुआ यह पढ़ना ही पूरा निदान है।

दो कार्य जो बाहर से एक जैसे दिखते हैं

कुंजी नवीनीकरण प्रोटोकॉल द्वारा परिभाषित विनिमय के अंतर्गत सुरक्षा संगठनों या कुंजी सामग्री को बदलता है। प्रमाणीकरण दोहराया नहीं जाता, इसलिए सत्र की शुरुआत में स्वीकार की गई पहचान बस आगे ले जाई जाती है।

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

कुंजी नवीनीकरण वास्तव में क्या बदलता है

IKEv2 अलग जीवनचक्र वाले दो प्रकार के संगठन रखता है। IKE SA नियंत्रण चैनल की रक्षा करता है, और CHILD SA वास्तविक ट्रैफ़िक की रक्षा करते हैं। एक को नवीनीकृत करना क्लाइंट को फिर से जोड़ने का पर्याय नहीं है।

यह अलगाव एक परिचित पैटर्न समझाता है: ट्रैफ़िक ठीक चलता है, फिर एक CHILD SA नवीनीकृत होता है और प्रस्ताव मेल नहीं खाता क्योंकि किसी ने हफ़्तों पहले एक तरफ़ चरण 2 संपादित कर दिया था। वह परिवर्तन तब तक बिना नुकसान के पड़ा रहा जब तक नवीनीकरण ने उसे लागू नहीं किया।

जीवनकाल की बेमेल स्थितियाँ भी वैसे ही व्यवहार करती हैं। जो पक्ष पहले अपनी सीमा तक पहुँचता है वही विनिमय शुरू करता है, और दूसरे को उसे स्वीकार करना होता है।

पुनः प्रमाणीकरण क्या फिर से मूल्यांकित करता है

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

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

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

कुछ भी बदलने से पहले टाइमस्टैम्प पढ़ें

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

strongSwan इसे अलग सेटिंग्स के रूप में प्रस्तुत करता है: rekey कुंजी नवीनीकरण नियंत्रित करता है, reauth नियंत्रित करता है कि नया प्रमाणीकरण होता है या नहीं, और margin मान तय करते हैं कि प्रत्येक समाप्ति से कितना पहले शुरू होता है। कुंजी नवीनीकरण का दस्तावेज़ अंतर्क्रिया का वर्णन करता है, और फ़ोरम पोस्ट से जीवनकाल कॉपी करने से पहले इसे पढ़ना उचित है।

इन सबको साधारण नेटवर्क हानि से अलग रखें। टूटा लिंक मृत पीयर पहचान घटना या पुनः प्रेषण तूफ़ान पैदा करता है, मेल खाते प्रस्तावों वाला साफ़ विनिमय नहीं।

जो विफल हुआ उसे बदलें

क्रेडेंशियल अस्वीकृति के लिए पहचान समस्या ठीक करनी होती है: प्रमाणपत्र नवीनीकृत करें, खाता बहाल करें, कारक फिर से पंजीकृत करें। प्रस्ताव या जीवनकाल की बेमेल के लिए दोनों पक्षों पर पैरामीटर की तुलना करनी होती है।

लक्षण से बचने के लिए जीवनकाल खींचना ही एकमात्र विकल्प है जो हमेशा काम करता दिखता है और कभी काम नहीं करता।

नियंत्रित नवीनीकरण का परीक्षण करें

एक दिन प्रतीक्षा करने के बजाय नवीनीकरण को बाध्य करें। फिर यदि परिनियोजन समर्थन दे तो पुनः प्रमाणीकरण के साथ दोहराएँ, और दोनों सिरों को देखें।

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