DPD टाइमर छोटा करने से VPN फ़ेलओवर तेज़ नहीं होगा

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

चार चरण, जिनमें से एक का समय आप माप सकते हैं

रिकवरी को टाइमस्टैम्प के साथ चार घटनाओं के रूप में लिखें। विफलता अवलोकन योग्य हो जाती है: अंतिम उपयोगी संरक्षित ट्रैफ़िक और पहला असफल अनुरोध। स्वामी तंत्र प्रतिक्रिया देता है: लाइवनेस पहचान, रूट मॉनिटर या कोई अन्य प्रलेखित ट्रिगर। विकल्प उपयोगी हो जाता है: पीयर चयन, प्रमाणीकरण, नया एसोसिएशन और एक रूट जो वास्तव में इच्छित ट्रैफ़िक ले जाता है। एप्लिकेशन ठीक हो जाता है: नया ऑपरेशन सफल होता है और जो चल रहा था उसका एक निश्चित परिणाम होता है।

IKEv2 के लाइवनेस नियम पीयर और उसके आदान-प्रदान के बारे में सबूत बताते हैं, और उस पीयर के पीछे किसी डेटाबेस या फ़ाइल सेवा के बारे में कुछ नहीं कहते। लाइवनेस टाइमआउट को पूरे पथ की स्वास्थ्य जाँच के रूप में पढ़ना वह गलती है जो टाइमर की खोज शुरू करती है।

टाइमर सबसे कम दिलचस्प संख्या क्यों है

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

अन्य चरण टाइमर बिल्कुल नहीं हैं। पुनः कनेक्शन बैकऑफ़, इंटरैक्टिव प्रमाणीकरण संकेत या ऐसा क्लाइंट जो केवल पुनरारंभ पर अपना कॉन्फ़िगरेशन फिर से आँकता है—इनमें से प्रत्येक रुकावट पर हावी हो सकता है जबकि हर प्रोटोकॉल टाइमर आराम से नीचे बैठा हो।

जो चरण वास्तव में धीमा है उसे मापें

विफलता को एक बार कैप्चर करें, दोनों ओर टाइमस्टैम्प के साथ, फिर प्रोटोकॉल के अपने काउंटरों के बजाय चार घटनाओं की तुलना करें। ठीक से किया गया एक अवलोकन विंडो एक महीने के ट्यूनिंग से बेहतर है।

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

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

विकल्प पहले से ही उपयोगी होना चाहिए

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

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

फ़ेलबैक उथल-पुथल और प्रबंधन पथ

प्राथमिक को बहाल करना एक अलग निर्णय है। आक्रामक फ़ेलबैक उस काम को बाधित कर सकता है जो बैकअप पर पहले ही ठीक हो चुका था, और डगमगाता पथ अस्थिर टनल जैसा दिख सकता है जब असली खराबी दो समान विकल्पों के बीच लगातार झूलता एक रूट हो।

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

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