तपाईंको VPN आउटेजभन्दा बढी समय किन लिन्छ पुनःप्राप्त हुन

Wi-Fi तीस सेकेन्ड अघि फर्कियो र VPN अझै बन्द छ, त्यसैले क्लाइन्ट बिग्रेको देखिन्छ। प्रायः यो आफ्नै पुनःप्रयास तालिका मात्र पछ्याइरहेको हुन्छ, र त्यो तालिकालाई नेटवर्क भर्खरै फर्केको कुरा थाहा हुँदैन। त्यही अन्तर सारा कथा हो: पुनःप्राप्तिको समय भन्नाले आउटेजसँगै क्लाइन्टले पहिले नै स्वीकार गरेको जुनसुकै प्रतीक्षा पनि। हरेक टाइमर घटाउनु एउटा उत्तर हो, र कुन टाइमर महत्त्वपूर्ण छ भन्ने बुझ्नु अर्को।

ट्युनिङले सहयोग गर्छ कि गर्दैन भन्ने तीन सर्तले तय गर्छ: कुन चरण ढिलो छ, असफलता नै पुनःप्रयासयोग्य छ कि छैन, र नेटवर्क फर्केको कुरा क्लाइन्टले कसरी थाहा पाउँछ।

एउटै जस्तो देखिने तीन प्रतीक्षा

एन्डपोइन्ट रिजोल्युसन, IKE वा TLS वार्ता, प्याकेट पुनःप्रेषण र नयाँ प्रयास सुरु गर्नु फरक टाइमर भएका फरक घटना हुन्। strongSwan ले पुनःप्रेषण ब्याकअफ IKE का लागि कागजात गर्छ, र OpenVPN सँग फरक अर्थसहित आफ्नै पुनःप्रयास नियन्त्रण छ। एउटाबाट अर्कोमा संख्या प्रतिलिपि गर्नु भनेको संयन्त्रहरू मिल्छन् भन्ने मान्नु हो, तर ती मिल्दैनन्। तपाईं कुन अन्तराल हेर्दै हुनुहुन्छ भनी निर्णय गर्नुअघि लगको क्रम पढ्नुहोस्।

लगमा एक मिनेट चुप्पी हुनु अनिवार्यतः जमेको प्रक्रिया हुँदैन। यो कुन कामका लागि सेट गरिएको हो ठ्याक्कै त्यही गरिरहेको घातीय ब्याकअफ हुन सक्छ।

वास्तवमा कुन चरण ढिलो छ?

यदि लगले प्रमाणीकरण त्रुटिसँग असफल हुने प्रयासहरू देखाउँछ भने कुनै टाइमर परिवर्तनले सहयोग गर्दैन, किनकि प्रमाणहरू गलत छन्। यदि प्रयासहरू नै गरिँदैनन् भने क्लाइन्ट आफ्नो प्रतीक्षा झ्यालभित्र छ र तालिका नै समाधान हो। यदि प्रयासहरू गरिन्छन् र समय सकिन्छ भने समस्या पहुँच वा अनुपस्थित श्रोतामा छ, र छिटो पुनःप्रयासले लग मात्र भर्छ। ती तीन अवस्थाका फरक मालिक छन्, र तीमध्ये एउटा मात्र समयको समस्या हो।

कुनै संख्यालाई छुनुअघि असफलताको वर्गीकरण गर्नुहोस्।

टाइमर घटाउनु कहिले सहयोग गर्छ र कहिले गर्दैन

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

हरेक प्रोफाइलमा प्रतिलिपि गरिएको धेरै कम समयसीमा नाप बिनाको ट्युनिङको सामान्य अन्तिम अवस्था हो।

क्लाइन्टलाई दोष दिनुअघि तयारी जाँच्नुहोस्

केही प्रयास नगरेसम्म क्लाइन्टले नेटवर्क प्रयोगयोग्य छ भनी देख्न सक्दैन। क्याप्टिभ पोर्टल, DHCP नवीकरण वा मार्ग परिवर्तनले यी सबै हुनुअघि तय भएको तालिकामा प्रतीक्षा गराउन सक्छ। अपरेटिङ सिस्टमको नेटवर्क अवस्था परिवर्तन र क्लाइन्टको अर्को प्रयास एउटै घडीमा हेर्नुहोस्, र कसको प्रतीक्षा हो देख्नुहुनेछ। छिटो तरिका भनेको नेटवर्क-तयार घटनाको समयछाप र त्यसपछिको पहिलो प्रयासको समयछाप टिप्नु हो।

प्रतीक्षाका क्रममा सिधा ट्राफिक अझै अवरुद्ध छ भनी पुष्टि गर्नुहोस्, किनकि ट्राफिक चुहाउने छिटो पुनःजडान सुधार होइन।

के टिप्ने

कुन टाइमर बदलियो, कुन मानबाट कुन मानमा, र त्यसपछि पुनःप्राप्ति कस्तो देखियो लेख्नुहोस्। क्लाइन्टको संस्करण पनि टिप्नुहोस्, किनकि पूर्वनिर्धारितहरू रिलिजहरूबीच सर्छन् र कागजात नगरिएको धेरै कम समयसीमाले प्रोफाइल पढ्ने अर्को व्यक्तिलाई अलमल्याउनेछ।

त्यो अभिलेखले अर्को सफ्टवेयर अपग्रेडलाई प्रयोगको सट्टा तुलना बनाउँछ।