आपका VPN आउटेज से ज़्यादा समय में क्यों ठीक होता है

Wi-Fi तीस सेकंड पहले लौटा और VPN अभी भी बंद है, इसलिए क्लाइंट टूटा हुआ लगता है। अक्सर वह बस अपने ही पुनःप्रयास शेड्यूल का पालन कर रहा होता है, और उस शेड्यूल को पता नहीं है कि नेटवर्क अभी-अभी लौटा है। यही अंतर पूरी कहानी है: पुनर्प्राप्ति का समय आउटेज के साथ-साथ वह इंतज़ार है जिसे क्लाइंट पहले ही स्वीकार कर चुका है। हर टाइमर घटाना एक जवाब है, और यह समझना कि कौन-सा टाइमर मायने रखता है दूसरा।

तीन शर्तें तय करती हैं कि ट्यूनिंग मदद करेगी या नहीं: कौन-सा चरण धीमा है, विफलता बिलकुल भी दोहराई जा सकती है या नहीं, और क्लाइंट को कैसे पता चलता है कि नेटवर्क लौट आया है।

तीन इंतज़ार जो एक जैसे दिखते हैं

एंडपॉइंट रिज़ॉल्यूशन, IKE या TLS बातचीत, पैकेट का दोबारा प्रेषण और नया प्रयास शुरू करना अलग टाइमर वाली अलग घटनाएँ हैं। strongSwan पुनःप्रेषण बैकऑफ़ का दस्तावेज़न IKE के लिए करता है, और OpenVPN के अपने पुनःप्रयास नियंत्रण अलग अर्थशास्त्र के साथ हैं। एक से दूसरे में संख्या की नकल यह मानती है कि तंत्र मेल खाते हैं, और वे नहीं मेल खाते। यह तय करने से पहले कि आप कौन-सा अंतराल देख रहे हैं, लॉग का क्रम पढ़ें।

लॉग में एक शांत मिनट ज़रूरी नहीं कि जमी हुई प्रक्रिया हो। यह एक चरघातांकी बैकऑफ़ हो सकता है जो ठीक वही कर रहा है जिसके लिए उसे सेट किया गया था।

असल में कौन-सा चरण धीमा है?

अगर लॉग दिखाता है कि प्रयास प्रमाणीकरण त्रुटि से विफल हो रहे हैं, तो कोई टाइमर बदलाव मदद नहीं करेगा, क्योंकि क्रेडेंशियल गलत है। अगर प्रयास बिलकुल नहीं किए जा रहे हैं, तो क्लाइंट अपनी प्रतीक्षा खिड़की के भीतर है और शेड्यूल ही समाधान है। अगर प्रयास किए जाते हैं और समय समाप्त हो जाता है, तो समस्या पहुँच या अनुपस्थित श्रोता है, और तेज़ पुनःप्रयास केवल लॉग भरता है। उन तीनों स्थितियों का अलग मालिक है, और उनमें से केवल एक समय की समस्या है।

किसी संख्या को छूने से पहले विफलता का वर्गीकरण करें।

टाइमर घटाना कब मदद करता है और कब नहीं

पुनःप्रयास की ऊपरी सीमा तब घटाएँ जब प्रमुख लागत छोटे, बार-बार होने वाले आउटेज के बाद का इंतज़ार हो, जैसे एक्सेस पॉइंट के बीच घूमता लैपटॉप। जब विफलताएँ लंबी या दुर्लभ हों तो उसे छेड़ें नहीं, क्योंकि आक्रामक पुनःप्रयास ठीक उसी क्षण भार जोड़ता है जब कॉन्संट्रेटर उत्तर देने में सबसे कम सक्षम होता है। दोनों ही स्थितियों में एक पैरामीटर बदलें, उसे दर्ज करें, और सुधरा मानने के बजाय अगली पुनर्प्राप्ति को मापें।

हर प्रोफ़ाइल में नकल किया गया बहुत कम टाइमआउट बिना मापन के ट्यूनिंग की सामान्य अंतिम स्थिति है।

क्लाइंट को दोष देने से पहले तैयारी जाँचें

क्लाइंट अक्सर यह नहीं देख सकता कि नेटवर्क उपयोगी है जब तक कुछ प्रयास न करे। कैप्टिव पोर्टल, DHCP नवीनीकरण या रूट परिवर्तन उसे ऐसे शेड्यूल पर इंतज़ार करा सकते हैं जो इन सबके पहले तय हुआ था। ऑपरेटिंग सिस्टम के नेटवर्क स्थिति परिवर्तन और क्लाइंट के अगले प्रयास को एक ही घड़ी पर देखें, और आप देखेंगे कि किसका इंतज़ार है। तेज़ तरीका यह है कि नेटवर्क-तैयार घटना का टाइमस्टैम्प और उसके बाद पहले प्रयास का टाइमस्टैम्प नोट करें।

यह भी पुष्टि करें कि इंतज़ार के दौरान सीधा ट्रैफ़िक अब भी अवरुद्ध है, क्योंकि ट्रैफ़िक लीक करने वाला तेज़ पुनःकनेक्शन सुधार नहीं है।

क्या दर्ज करें

लिखें कि कौन-सा टाइमर बदला, किस मान से किस मान में, और उसके बाद पुनर्प्राप्ति कैसी दिखी। क्लाइंट का संस्करण भी नोट करें, क्योंकि डिफ़ॉल्ट रिलीज़ के बीच बदलते हैं और अप्रलेखित बहुत कम टाइमआउट प्रोफ़ाइल पढ़ने वाले अगले व्यक्ति को उलझा देगा।

वह रिकॉर्ड अगले सॉफ़्टवेयर अपग्रेड को प्रयोग के बजाय तुलना में बदल देता है।