प्रत्येक वेळी किल्ल्या फिरतात तेव्हा तुमचा VPN का तुटतो

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

लेबल नाही, टप्पा वाचा

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

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

OpenVPN साठी समतुल्य घटना म्हणजे आवृत्ती आणि तैनाती सेटिंग्ज नियंत्रित करणारी पुनर्बोलणी। तिच्या प्रमाणीकरण वर्तनाचे स्वतःचे अयशस्वी होण्याचे मार्ग आहेत। महत्त्वाचा संदेश अयशस्वी टप्प्याचे नाव घेतो, आणि तिकिटात पुन्हा लिहिण्याऐवजी तो शब्दशः नोंदवला पाहिजे।

वेळ-ठसेही लिहा। शेवटच्या यशस्वी बोलणीनंतर ठराविक अंतराने तुटणे हे वापरादरम्यान अचानक येणाऱ्यापेक्षा पूर्णपणे वेगळे निष्कर्ष आहे, आणि ते अंतरच बहुतेक वेळा टिकून राहणारा एकमेव पुरावा असतो।

अयशस्वी होणाऱ्या प्रस्तावाची तुलना करा

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

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

जुना प्रोफाइल किंवा पुरवठादाराचा टेम्पलेट असा प्रस्ताव पिन करू शकतो जो सध्याची आवृत्ती आता देत नाही। विसंगती फक्त नवीन बोलणी सक्तीने केल्यावरच दिसते।

क्रेडेन्शियलची अडचण अगम्य सहकाऱ्यापासून वेगळी करा

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

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

नेटवर्कला दोष देण्यापूर्वी प्रमाणपत्राच्या तारखा आणि खात्याची स्थिती तपासा। दोन्ही तपासणे स्वस्त आहे आणि दोन्ही क्लायंटच्याच संदेशात अदृश्य आहेत।

एक नूतनीकरण सक्तीने करा आणि निकाल वाचा

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

दुरुस्ती झाल्यावर नूतनीकृत सुरंग तपासा आणि नंतर ॲपमधून नवीन विनंती करा। असोसिएशन बदलले तेव्हा सक्रिय असलेल्या ॲप सत्राला सुरंग पुन्हा निरोगी असूनही स्वतःची पुनर्प्राप्ती लागू शकते। वापरकर्ते ते VPN अजूनही तुटलेले आहे असे नोंदवतील।

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