IKEv2: की नूतनीकरण व पुनः प्रमाणीकरण — कनेक्शन नंतर का तुटते
एक की सामग्रीचे नूतनीकरण करते, दुसरे ओळख तपासणीची पुनरावृत्ती करते। तुमच्या सत्राने कोणती सीमा ओलांडली यावर काय दुरुस्त करायचे हे ठरते।
बोगदा सकाळी वर येतो आणि तासन्तास काम करतो। मग तो तुटतो, एका प्रयत्नानंतर पुन्हा जोडला जातो आणि दुसऱ्या दिवशीही तेच करतो। नेटवर्कवर काहीही बदलले नाही आणि कोणीही पासवर्डला हात लावला नाही। नूतनीकरण सीमेवर अयशस्वी होणारी सत्रे सामान्यतः दोन वेगळ्या क्रियांपैकी एक ओलांडतात, आणि त्यापैकी फक्त एकच तुमची ओळखपत्रे पुन्हा तपासते। कोणती सक्रिय झाली हे वाचणे हेच संपूर्ण निदान आहे।
बाहेरून एकसारख्या दिसणाऱ्या दोन क्रिया
की नूतनीकरण प्रोटोकॉलने ठरवलेल्या देवाणघेवाणीअंतर्गत सुरक्षा संघटना किंवा की सामग्री बदलते। प्रमाणीकरण पुनरावृत्त होत नाही, म्हणून सत्राच्या सुरुवातीला स्वीकारलेली ओळख फक्त पुढे नेली जाते।
पुनः प्रमाणीकरण अधिक पुढे जाते: ते नवीन प्रमाणित संबंध प्रस्थापित करते, म्हणजे ओळखपत्रांचे पुन्हा मूल्यांकन होते। जे संपले, रद्द झाले किंवा डिरेक्टरीमध्ये बदलले ते त्याच क्षणी दिसते।
की नूतनीकरण प्रत्यक्षात काय बदलते
IKEv2 वेगवेगळ्या जीवनचक्रांसह दोन प्रकारच्या संघटना ठेवते। IKE SA नियंत्रण चॅनेलचे रक्षण करते आणि CHILD SA प्रत्यक्ष रहदारीचे। एक नूतनीकरण करणे क्लायंट पुन्हा जोडण्याचा समानार्थी नाही।
हा भेद एक परिचित नमुना स्पष्ट करतो: रहदारी व्यवस्थित वाहते, मग एक CHILD SA नूतनीकृत होते आणि प्रस्ताव जुळत नाही कारण कोणी अनेक आठवड्यांपूर्वी एका बाजूला टप्पा 2 संपादित केला होता। तो बदल नूतनीकरणाने तो वापरून पाहण्यापर्यंत तिथे निरुपद्रवी पडलेला होता।
आयुष्यमानातील तफावतही तशीच वागते। जी बाजू आधी आपल्या मर्यादेपर्यंत पोहोचते ती देवाणघेवाण सुरू करते, आणि दुसऱ्याला ती स्वीकारावी लागते।
पुनः प्रमाणीकरण काय पुन्हा मूल्यांकन करते
पुनः प्रमाणीकरणात, लॉगिनच्या वेळी वैध असलेले क्लायंट प्रमाणपत्र आता कालबाह्य झालेले असू शकते। रद्द केलेले ओळखपत्र, बदललेला पासवर्ड किंवा उपलब्ध नसलेला दुसरा घटक हे सर्व इथेच समोर येतात, नूतनीकरणाच्या वेळी नाही।
म्हणूनच प्रत्येक आयुष्यमान वाढवणे दुरुस्ती वाटते आणि ती नाही। तुम्ही तपासणी पास करण्याऐवजी पुढे ढकलली आहे। पुढील नूतनीकरण त्याच दोषासह आणि तो लक्षात घेण्यासाठी लहान व्यत्ययाच्या खिडकीसह येते।
काही अंमलबजावण्या पुनः प्रमाणीकरणादरम्यान जुनी आणि नवीन स्थिती एकमेकांवर ठेवतात। इतर थोडीशी तफावत निर्माण करतात। त्यामुळे दोन विक्रेत्यांवर एकसारख्या सेटिंग्ज वेगळा वापरकर्ता अनुभव देऊ शकतात। मानकच हे ठरवते असे गृहीत धरण्याऐवजी वर्तन तपासा।
काहीही बदलण्यापूर्वी टाइमस्टॅम्प वाचा
अयशस्वीतेचा क्षण संघटनेच्या आधीच्या आणि नंतरच्या स्थितीसह नोंदवा। जर जुनी संघटना प्रमाणीकरण देवाणघेवाणीशिवाय बदलली गेली असेल, तर तुम्ही नूतनीकरण सीमेवर होता। जर अयशस्वीतेच्या अगदी आधी AUTH देवाणघेवाण दिसली, तर तुम्ही पुनः प्रमाणीकरणावर होता।
strongSwan हे वेगळ्या सेटिंग्ज म्हणून उघड करते: rekey की नूतनीकरण नियंत्रित करते, reauth नवीन प्रमाणीकरण होते की नाही हे नियंत्रित करते, आणि margin मूल्ये प्रत्येक कालबाह्यतेच्या किती आधी सुरू होते हे ठरवतात। की नूतनीकरणाचे दस्तऐवज परस्परसंवादाचे वर्णन करते, आणि फोरम पोस्टमधून आयुष्यमान कॉपी करण्यापूर्वी ते वाचणे योग्य आहे।
हे सर्व साधारण नेटवर्क हानीपासून वेगळे ठेवा। तुटलेला दुवा मृत पीअर शोध घटना किंवा पुनः पाठवणीचे वादळ निर्माण करतो, जुळणाऱ्या प्रस्तावांसह स्वच्छ देवाणघेवाण नाही।
जे अयशस्वी झाले ते बदला
ओळखपत्र नाकारण्यासाठी ओळखीची समस्या दुरुस्त करावी लागते: प्रमाणपत्र नूतनीकृत करा, खाते पुनर्संचयित करा, घटक पुन्हा नोंदवा। प्रस्ताव किंवा आयुष्यमानाची तफावत दोन्ही बाजूंच्या पॅरामीटर्सची तुलना करणे आवश्यक करते।
लक्षण टाळण्यासाठी आयुष्यमाने ताणणे हा एकमेव पर्याय आहे जो नेहमी काम केल्यासारखा दिसतो आणि कधीही काम करत नाही।
नियंत्रित नूतनीकरणाची चाचणी करा
एक दिवस वाट पाहण्याऐवजी नूतनीकरण सक्तीने करा। नंतर तैनातीला समर्थन असल्यास पुनः प्रमाणीकरणासह पुनरावृत्ती करा, आणि दोन्ही टोके पाहा।
यशस्वी प्रारंभिक लॉगिन यापैकी काहीही सराव करत नाही। त्यानंतरचे जीवनचक्र हेच अशा तैनाती खरोखर तुटतात ते ठिकाण आहे।