तुमचा IPsec बोगदा पहिल्या CHILD SA किल्ली नूतनीकरणापर्यंतच का चालतो

बोगदा वर आला, ping ने उत्तर दिले आणि सर्वांनी मान्यता दिली। चार तासांनंतर सत्र पडते, दोन्ही बाजू प्रस्ताव किंवा किल्ली-देवाणघेवाणीची त्रुटी नोंदवतात, आणि पहिला अंदाज असतो की नेटवर्कवर काहीतरी बदलले। काहीच बदलले नाही। हालचाल वाहणाऱ्या बोगद्याने सिद्ध केले आहे की दोन्ही बाजू प्रमाणीकरण कसे करायचे आणि पहिली चाइल्ड असोसिएशन कशी संरक्षित करायची यावर सहमत आहेत, आणि नूतनीकरणात ते मागणार असलेल्या किल्ली देवाणघेवाणीबद्दल काहीही सिद्ध केले नाही। विसंगती त्या दोन घटनांमधील फटीत बसलेली आहे।

जोडलेले असणे म्हणजे PFS सेटिंग्ज जुळतात असे नाही

IKEv2 मध्ये, पहिली चाइल्ड असोसिएशन प्रमाणीकरण देवाणघेवाणीदरम्यान तयार होते, आणि तिच्या किल्ल्या IKE असोसिएशनने आधीच तयार केलेल्या सामग्रीतून घेतल्या जातात। त्या चाइल्डसाठी वेगळी Diffie-Hellman देवाणघेवाण होत नाही, त्यामुळे नूतनीकरणात ती मागणारे धोरण उभारणीच्या वेळी तपासले जात नाही।

नूतनीकरण ही वेगळी देवाणघेवाण आहे। चाइल्ड असोसिएशनची किल्ली नूतनीकृत होते तेव्हा बाजू त्यांच्या प्रस्तावांत नमूद केलेल्या गटासह नवीन किल्ली देवाणघेवाण करू शकतात, आणि गटाच्या सेटिंग्जची पहिल्यांदा तुलना होण्याचा तोच क्षण आहे। त्यामुळे असहमत दोन बाजू प्रमाणीकरण करून, चाइल्ड असोसिएशन स्थापित करून हालचाल पास करू शकतात, आणि नंतर नूतनीकरणात अपयशी होऊ शकतात।

प्रस्ताव स्ट्रिंगमध्ये विसंगती कुठे लपली आहे

strongSwan मध्ये गट चाइल्ड प्रस्तावाला जोडला जातो, म्हणून aes256gcm16-prfsha256-ecp256 सारखी स्ट्रिंग कूटबद्धीकरणाची निवड वाटते पण किल्ली देवाणघेवाणीची अटही बाळगते। फक्त aes256gcm16-prfsha256 देऊ करणाऱ्या बाजूकडे अशी अट नसते, आणि दोन्ही याद्या कूटबद्धीकरणावर एकत्र येतात पण देवाणघेवाणीवर वेगळ्या पडतात।

चाइल्ड प्रस्ताव आणि IKE प्रस्ताव वेगळ्या याद्या म्हणून वाचा। IKE यादीत दिसणारा गट चाइल्ड यादीबद्दल काहीही सांगत नाही, आणि एक वाचताना दुसरी संपादित करणे हा हे चुकवण्याचा नेहमीचा मार्ग आहे।

अपयश वाचा, तुम्ही संपादित केलेली फाइल नाही

देवाणघेवाण संपवणारा notify शोधा। कोणताही स्वीकार्य प्रस्ताव न परतवणारे चाइल्ड किल्ली नूतनीकरण प्रस्ताव याद्यांकडे निर्देश करते; कधीही उत्तर न मिळणारी नूतनीकरण विनंती मार्गाकडे किंवा ऐकणे थांबवलेल्या बाजूकडे निर्देश करते। या दोन्हींना वेगळे दुरुस्ती लागते, आणि लॉग ओळीची शब्दरचना त्या वेगळ्या करते।

डिस्कवरील नाही, चालू कॉन्फिगरेशनची खात्री करा। जतन केलेली पण लोड न केलेली फाइल, किंवा दुसऱ्या include मधून पुन्हा वाचलेले कनेक्शन, अशी विसंगती निर्माण करेल जी दिसणारी फाइल कितीही संपादित केली तरी सुटणार नाही।

सर्वांनी किल्ली नूतनीकरण म्हणून संबोधली जाणारी तीन घटना

IKE असोसिएशनच्या किल्लीचे नूतनीकरण, IKE पुनर्प्रमाणीकरण आणि चाइल्ड असोसिएशनच्या किल्लीचे नूतनीकरण या वेगळ्या प्रस्ताव नियमांसह वेगळ्या क्रिया आहेत। त्यांपैकी एकात नोंदवलेले अपयश इतरांबद्दल थेट काहीही सांगत नाही, आणि त्यांना मिसळणारा लॉग तीन असूनही एक पुनरावृत्त बिघाड म्हणून वाचला जातो।

बाजू कोणत्या घटनेचे नाव घेते ते लक्षात घ्या, नंतर फक्त त्या घटनेसाठी प्रस्ताव तपासा। एक यादी बदला, पुन्हा लोड करा आणि तीच घटना पुन्हा बळजबरीने घडवा। लॉग पुनर्प्रमाणीकरणाचे नाव घेत असेल, तर IKE प्रस्ताव वाचायचा आहे। चाइल्ड किल्ली नूतनीकरणाचे नाव घेत असेल, तर महत्त्वाचा गट चाइल्ड प्रस्ताव बाळगतो।

नूतनीकरण बंद करणे हा उपाय नाही

किल्ली नूतनीकरणाची वेळ शून्यावर ठेवल्याने अपयशी होणारी देवाणघेवाण दाबली जाते, आणि बोगदा नंतर तुटण्यापर्यंत किंवा बाजू पुन्हा सुरू होण्यापर्यंत टिकतो। तुम्ही विकत घेतलेला लांब आयुष्याचा किल्ली आणि स्थलांतर, लेखापरीक्षण किंवा विक्रेता अद्यतनाच्या वेळी पुन्हा भेटणारी विसंगती आहे। दुसऱ्या बाजूच्या अपेक्षित धोरणाच्या खूप पुढे ताणलेल्या आयुष्यांनाही तेच लागू आहे।

त्याऐवजी प्रस्ताव एकरेष करा। दोन्ही बाजू अंमलात आणतात असा गट निवडा, तो दोन्ही टोकांवर चाइल्ड प्रस्तावात ठेवा, आणि नूतनीकरण धोरण संस्थेला खरोखर आवश्यक असलेल्या मर्यादेत ठेवा।

अपयशी झालेल्या देवाणघेवाणीने ते सिद्ध करा

देखभाल विंडोमध्ये चाइल्ड किल्ली नूतनीकरणाची वेळ कमी करा, जेणेकरून घटना तासांऐवजी मिनिटांत येईल, किंवा हाताने चाइल्ड किल्ली नूतनीकरण चालवा। नंतर यशस्वी नूतनीकरण पाहा आणि हालचाल त्यातून सुरू राहते याची खात्री करा, कारण चाइल्ड असोसिएशन स्थापित करणारे पण अनुप्रयोग प्रवाह सोडणारे नवीन हस्तांदोलन वेगळा दोष आहे।

नंतर सामान्य आयुष्य पुनर्स्थापित करा आणि दोन्ही घटना नोंदी ठेवा, अपयशी आणि यशस्वी। तुम्हाला हवा असलेला पुरावा असा आहे की जोडणी स्वतःचे जीवनचक्र टिकून राहते, ping टिकला हे नाही।