DPD टाइमर छोटो गर्दा VPN फेलओभर छिटो हुँदैन

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

चार चरण, तीमध्ये एउटाको समय तपाईं नाप्न सक्नुहुन्छ

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

IKEv2 का जीवितता नियम ले पियर र त्यसका आदानप्रदानबारे प्रमाण वर्णन गर्छन्, र त्यो पियरपछाडिको डेटाबेस वा फाइल सेवाबारे केही भन्दैनन्। जीवितता समाप्तिलाई सम्पूर्ण मार्गको स्वास्थ्य जाँचका रूपमा पढ्नु टाइमरको सिकार सुरु गर्ने गल्ती हो।

टाइमर सबैभन्दा कम रोचक संख्या किन हो

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

अरू चरण टाइमर नै होइनन्। पुनःजडान ब्याकअफ, अन्तरक्रियात्मक प्रमाणीकरण सङ्केत वा पुनःसुरु गर्दा मात्र आफ्नो कन्फिगरेसन पुनर्मूल्याङ्कन गर्ने क्लाइन्ट — यीमध्ये प्रत्येकले अवरोधमा हावी हुन सक्छ, जबकि हरेक प्रोटोकल टाइमर आरामसँग तल बसेको हुन्छ।

वास्तवमै ढिलो चरण नाप्नुहोस्

विफलता एक पटक, दुवैतिर समय-छापसहित समात्नुहोस्, त्यसपछि प्रोटोकलका आफ्नै काउन्टरको सट्टा चार घटना तुलना गर्नुहोस्। राम्ररी गरिएको एउटा अवलोकन विन्डो एक महिनाको ट्युनिङभन्दा राम्रो हुन्छ।

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

वैकल्पिक अन्त्यबिन्दुले कहिल्यै जवाफ नदिए, टाइमरको कुनै पनि परिवर्तनले सहयोग गर्दैन, किनकि पुग्न नसकिनु पहिचानको समस्या होइन। नयाँ सुरक्षा अवस्था छिटो बने पनि मार्ग अझै मृत मार्गतिर देखाइरहेको छ भने, समस्या मार्ग स्थापनामा छ र अर्को जीवितता समायोजनले अस्थिरता मात्र थप्छ।

विकल्प पहिल्यै उपयोगी हुनुपर्छ

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

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

फेलब्याक अस्थिरता र व्यवस्थापन मार्ग

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

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

त्यसपछि त्यही कार्यभार दोहोर्याउनुहोस् र त्यही चार समय-छाप तुलना गर्नुहोस्। त्यही छुटेको मार्ग वा लगइनको प्रतीक्षा अनुप्रयोगलाई गराइरहने छोटो पुनःप्राप्ति प्रगति होइन, त्यो त्यही ग्राफमा अर्को संख्या हो।