आपका IPsec टनल पहले CHILD SA कुंजी नवीनीकरण तक ही क्यों काम करता है

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

कनेक्टेड होने का मतलब यह नहीं कि PFS सेटिंग्स मेल खाती हैं

IKEv2 के साथ, पहली चाइल्ड एसोसिएशन प्रमाणीकरण अदला-बदली के दौरान बनती है, और उसकी कुंजियाँ उस सामग्री से निकाली जाती हैं जो IKE एसोसिएशन पहले ही पैदा कर चुकी है। उस चाइल्ड के लिए अलग Diffie-Hellman अदला-बदली नहीं होती, इसलिए नवीनीकरण में उसकी मांग करने वाली नीति उठान के समय जाँची नहीं जाती।

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

प्रस्ताव स्ट्रिंग में असंगति कहाँ छिपी है

strongSwan में समूह चाइल्ड प्रस्ताव में जोड़ा जाता है, इसलिए aes256gcm16-prfsha256-ecp256 जैसी स्ट्रिंग एन्क्रिप्शन का चुनाव लगती है पर कुंजी-अदला-बदली की आवश्यकता भी रखती है। जो साथी केवल aes256gcm16-prfsha256 प्रस्तावित करता है उसके पास ऐसी आवश्यकता नहीं है, और दोनों सूचियाँ एन्क्रिप्शन पर मिलती हैं पर अदला-बदली पर अलग पड़ती हैं।

चाइल्ड प्रस्ताव और IKE प्रस्ताव को अलग सूचियों की तरह पढ़ें। IKE सूची में दिखने वाला समूह चाइल्ड सूची के बारे में कुछ नहीं कहता, और एक को पढ़ते हुए दूसरी को संपादित करना ही इसे चूकने का आम तरीका है।

विफलता पढ़ें, जिस फ़ाइल को आपने संपादित किया वह नहीं

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

डिस्क पर पड़ी नहीं, चल रही कॉन्फ़िगरेशन की पुष्टि करें। सहेजी गई पर लोड न हुई फ़ाइल, या किसी दूसरे include से फिर पढ़ा गया कनेक्शन, ऐसी असंगति पैदा करेगा जिसे दिखने वाली फ़ाइल को कितना भी संपादित करने से ठीक नहीं किया जा सकता।

तीन घटनाएँ जिन्हें सभी कुंजी नवीनीकरण कहते हैं

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

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

नवीनीकरण बंद करना समाधान नहीं है

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

इसके बजाय प्रस्तावों को एक-साथ लाएँ। ऐसा समूह चुनें जिसे दोनों साथी लागू करते हों, उसे दोनों सिरों पर चाइल्ड प्रस्ताव में रखें, और नवीनीकरण नीति को उसी दायरे में रखें जो संस्था को वास्तव में चाहिए।

इसे उसी अदला-बदली से साबित करें जो विफल हुई

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

बाद में सामान्य आयु बहाल करें और दोनों घटना रिकॉर्ड रखें, विफल और सफल। आप जो प्रमाण चाहते हैं वह यह है कि कनेक्शन अपने जीवन-चक्र में टिका रहे, यह नहीं कि उसने ping झेल लिया।