तुमचा VPN बंद पडण्यापेक्षा जास्त वेळ का घेतो पुन्हा सुरू होण्यास

Wi-Fi तीस सेकंदांपूर्वी परत आले आणि VPN अजूनही बंद आहे, त्यामुळे क्लायंट तुटलेला दिसतो. बऱ्याचदा तो फक्त आपल्या स्वतःच्या पुनर्प्रयत्नाच्या वेळापत्रकाचे पालन करत असतो, आणि त्या वेळापत्रकाला माहीत नसते की नेटवर्क आत्ताच परत आले आहे. तेच अंतर संपूर्ण कथा आहे: पुनर्प्राप्तीचा वेळ म्हणजे बंद पडणे आणि क्लायंटने आधीच मान्य केलेली कोणतीही प्रतीक्षा यांची बेरीज. प्रत्येक टाइमर कमी करणे हे एक उत्तर आहे, आणि कोणता टाइमर महत्त्वाचा आहे हे समजून घेणे हे दुसरे.

तीन अटी ठरवतात की ट्युनिंग मदत करेल की नाही: कोणता टप्पा संथ आहे, अपयश अजिबात पुन्हा करण्यायोग्य आहे का, आणि नेटवर्क परत आले हे क्लायंटला कसे कळते.

एकासारखे दिसणारे तीन प्रतीक्षा

एंडपॉइंट रिझोल्यूशन, IKE किंवा TLS चर्चा, पॅकेटचे पुनःप्रेषण आणि नवीन प्रयत्न सुरू करणे वेगवेगळ्या टाइमरसह वेगवेगळ्या घटना आहेत. strongSwan पुनःप्रेषण बॅकऑफ IKE साठी दस्तऐवजीकरण करते, आणि OpenVPN कडे वेगळ्या अर्थासह स्वतःचे पुनर्प्रयत्न नियंत्रण आहे. एकातून दुसऱ्यात संख्या कॉपी करणे म्हणजे यंत्रणा जुळतात असे गृहीत धरणे, पण त्या जुळत नाहीत. तुम्ही कोणते अंतर पाहत आहात हे ठरवण्यापूर्वी लॉगचा क्रम वाचा.

लॉगमधील शांत मिनिट म्हणजे गोठलेली प्रक्रिया असेलच असे नाही. ती ज्यासाठी सेट केली होती तेच करणारी घातांकी बॅकऑफ असू शकते.

प्रत्यक्षात कोणता टप्पा संथ आहे?

लॉग प्रमाणीकरण त्रुटीने अयशस्वी होणारे प्रयत्न दाखवत असेल, तर कोणताही टाइमर बदल मदत करणार नाही, कारण क्रेडेन्शियल चुकीचे आहे. प्रयत्नच केले जात नसतील, तर क्लायंट आपल्या प्रतीक्षा खिडकीत आहे आणि वेळापत्रक हाच उपाय आहे. प्रयत्न केले जातात आणि वेळ संपतो, तर समस्या पोहोच किंवा अनुपस्थित श्रोत्यात आहे, आणि वेगाने पुन्हा प्रयत्न केल्याने फक्त लॉग भरतो. त्या तीनही अवस्थांचा वेगळा मालक आहे, आणि त्यातील फक्त एकच वेळेची समस्या आहे.

कोणत्याही संख्येला स्पर्श करण्यापूर्वी अपयशाचे वर्गीकरण करा.

टाइमर कमी करणे कधी मदत करते आणि कधी नाही

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

प्रत्येक प्रोफाइलमध्ये कॉपी केलेला अतिशय कमी कालावधी हा मोजमापाशिवाय ट्युनिंगचा नेहमीचा अंतिम टप्पा आहे.

क्लायंटला दोष देण्यापूर्वी तयारी तपासा

काहीतरी प्रयत्न करेपर्यंत नेटवर्क वापरण्यायोग्य आहे हे क्लायंटला बऱ्याचदा दिसत नाही. कॅप्टिव्ह पोर्टल, DHCP नूतनीकरण किंवा मार्ग बदल यामुळे तो हे सर्व घडण्यापूर्वी ठरवलेल्या वेळापत्रकावर थांबू शकतो. ऑपरेटिंग सिस्टमच्या नेटवर्क स्थितीतील बदल आणि क्लायंटचा पुढील प्रयत्न एकाच घड्याळावर पाहा, आणि कोणाची प्रतीक्षा आहे ते तुम्हाला दिसेल. वेगवान आवृत्ती म्हणजे नेटवर्क-तयार घटनेची वेळमुद्रा आणि त्यानंतरच्या पहिल्या प्रयत्नाची वेळमुद्रा नोंदवणे.

प्रतीक्षेदरम्यान थेट रहदारी अजूनही अडवलेली आहे याची खात्री करा, कारण रहदारी गळणारे जलद पुनःकनेक्शन सुधारणा नाही.

काय नोंदवायचे

कोणता टाइमर बदलला, कोणत्या मूल्यावरून कोणत्या मूल्यात, आणि त्यानंतर पुनर्प्राप्ती कशी दिसली ते लिहा. क्लायंटची आवृत्तीही नोंदवा, कारण डीफॉल्ट आवृत्त्यांमध्ये बदलतात आणि नोंद न केलेला अतिशय कमी कालावधी प्रोफाइल वाचणाऱ्या पुढील व्यक्तीला गोंधळात टाकेल.

ती नोंद पुढील सॉफ्टवेअर अपग्रेडला प्रयोगाऐवजी तुलना बनवते.