तपाईंको IPsec सुरुङ पहिलो CHILD SA कुञ्जी नवीकरणसम्म मात्र किन काम गर्छ

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

जोडिएको हुनु भनेको PFS सेटिङ मिल्छ भन्ने होइन

IKEv2 मा, पहिलो चाइल्ड एसोसिएसन प्रमाणीकरण आदानप्रदानका क्रममा बन्छ, र त्यसका कुञ्जीहरू IKE एसोसिएसनले पहिले नै उत्पादन गरेको सामग्रीबाट निकालिन्छन्। त्यो चाइल्डका लागि छुट्टै Diffie-Hellman आदानप्रदान हुँदैन, त्यसैले नवीकरणमा त्यस्तो माग गर्ने नीति उठाउने बेला परीक्षण गरिँदैन।

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

प्रस्ताव स्ट्रिङमा अमिल कहाँ लुकेको छ

strongSwan मा समूह चाइल्ड प्रस्तावमा थपिन्छ, त्यसैले aes256gcm16-prfsha256-ecp256 जस्तो स्ट्रिङ इन्क्रिप्सनको छनोटजस्तो देखिन्छ तर कुञ्जी आदानप्रदानको आवश्यकता पनि बोक्छ। केवल aes256gcm16-prfsha256 प्रस्ताव गर्ने पक्षसँग त्यस्तो आवश्यकता हुँदैन, र दुवै सूची इन्क्रिप्सनमा मिल्छन् तर आदानप्रदानमा फरक पर्छन्।

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

असफलता पढ्नुहोस्, तपाईंले सम्पादन गरेको फाइल होइन

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

डिस्कमा भएको होइन, चलिरहेको कन्फिगरेसन पुष्टि गर्नुहोस्। सुरक्षित तर लोड नगरिएको फाइल, वा अर्को include बाट फेरि पढिएको जडानले देखिने फाइल जतिसुकै सम्पादन गरे पनि नसुधारिने अमिल उत्पन्न गर्छ।

सबैले कुञ्जी नवीकरण भन्ने तीन घटना

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

पक्षले कुन घटनाको नाम लिन्छ ध्यान दिनुहोस्, त्यसपछि त्यही घटनाका लागि मात्र प्रस्ताव जाँच्नुहोस्। एउटा सूची बदल्नुहोस्, पुनः लोड गर्नुहोस् र त्यही घटना फेरि बल गर्नुहोस्। यदि लगले पुनःप्रमाणीकरणको नाम लिन्छ भने पढ्नुपर्ने IKE प्रस्ताव हो। यदि यसले चाइल्ड कुञ्जी नवीकरणको नाम लिन्छ भने महत्त्वपूर्ण समूह चाइल्ड प्रस्तावले बोक्छ।

नवीकरण बन्द गर्नु समाधान होइन

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

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

असफल भएको आदानप्रदानले प्रमाणित गर्नुहोस्

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

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