पुन्हा की, पुन्हा कनेक्ट किंवा पुन्हा प्रमाणीकरण: तुम्हाला कोणते हवे?

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

निर्णय कोणता थर प्रत्यक्षात संपला यावर अवलंबून आहे।

रोटेशन म्हणून ओळखल्या जाणाऱ्या तीन क्रिया

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

पुन्हा कनेक्ट कनेक्शन टाकून देते आणि सुरुवातीपासून पुन्हा बांधते, ज्यामुळे पत्ता वाटप, राउटिंग स्थापना आणि पहिल्या प्रयत्नाची प्रत्येक बोलणी पुन्हा होते।

पुन्हा प्रमाणीकरण ओळखीचा पुरावाच पुन्हा करते, ज्यात क्रेडेन्शियल, प्रमाणपत्र किंवा दुसरा घटक असू शकतो। उत्पादनानुसार हे पुन्हा कनेक्टसह किंवा त्याशिवाय होऊ शकते।

नूतनीकरणाच्या वेळी वापरकर्ते काय लक्षात घेतात

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

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

प्रत्यक्षात तिन्ही कुठे वेगळे होतात

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

प्रोटोकॉलची डीफॉल्ट मूल्ये सहसा योग्य उत्तर देतात। WireGuard कोणत्याही वापरकर्ता कृतीशिवाय वेळ आणि डेटा-आकार उंबरठ्यानंतर की बदलते; IKEv2 चे आयुष्यमान प्रत्येक चाइल्ड असोसिएशनसाठी ठरवले जातात; TLS-आधारित टनेल विद्यमान सत्राच्या आत की फिरवतात। वारंवार येणारी त्रुटी टाळण्यासाठी आयुष्यमान वाढवणे अपयश पुढे ढकलते आणि की लीक झाल्यास एक्सपोजर लांबवते।

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

डीफॉल्ट निवडा, नंतर टप्पा नोंदवा

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

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

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