DPD टाइमर कमी केल्याने VPN फेलओव्हर वेगवान होणार नाही

बोगदे पडतात, पुनर्प्राप्तीला नव्वद सेकंद लागतात, आणि डेड-पीअर टाइमर दहावर सेट आहे, म्हणून टाइमरला दोष दिला जातो। हा युक्तिवाद शोधानंतर होणाऱ्या आणि सहसा बहुतेक वेळ घेणाऱ्या तीन टप्प्यांकडे दुर्लक्ष करतो। जिवंतपणाचा शोध शांतता लक्षात घेतो; नंतर पीअर निवड, प्रमाणीकरण, मार्ग स्थापना आणि अनुप्रयोग पुनर्जोडणी प्रत्येकाने आपली पाळी घेतली जाते। पहिला टप्पा कमी केल्याने इतर कमी होत नाहीत, आणि आधीच झगडणाऱ्या प्रणालीत ते अधिक अस्थिरता आणू शकते।

चार टप्पे, त्यापैकी एकाची वेळ तुम्ही मोजू शकता

पुनर्प्राप्ती वेळ-शिक्क्यांसह चार घटना म्हणून लिहा। अपयश निरीक्षणक्षम होते: शेवटचा उपयुक्त संरक्षित रहदारी आणि पहिली अयशस्वी विनंती। मालक यंत्रणा प्रतिक्रिया देते: जिवंतपणाचा शोध, मार्ग मॉनिटर किंवा अन्य दस्तऐवजीकृत ट्रिगर। पर्याय उपयुक्त होतो: पीअर निवड, प्रमाणीकरण, नवीन सहयोग आणि हेतू असलेली रहदारी प्रत्यक्षात वाहून नेणारा मार्ग। अनुप्रयोग पुनर्प्राप्त होतो: नवीन क्रिया यशस्वी होते आणि जे चालू होते त्याचा निश्चित परिणाम असतो।

IKEv2 चे जिवंतपणाचे नियम पीअर आणि त्याच्या देवघेवीबद्दल पुरावे वर्णन करतात, आणि त्या पीअरमागील डेटाबेस किंवा फाइल सेवेबद्दल काहीही सांगत नाहीत। जिवंतपणाची मुदत संपणे हे संपूर्ण मार्गाची आरोग्य तपासणी म्हणून वाचणे ही टाइमरची शिकार सुरू करणारी चूक आहे।

टाइमर सर्वात कमी रोचक संख्या का आहे

संरचित मूल्ये अदलाबदल करण्यायोग्य एकके नाहीत। काही पुनर्प्रयत्न अंतराल आहेत, काही प्रयत्नाच्या वरच्या मर्यादा आहेत, आणि काही इतरांसोबत समांतर चालतात। ती एकत्र बेरजल्यास अंदाजासारखी दिसणारी आणि अफवेसारखी वागणारी संख्या तयार होते। तुम्ही स्पर्श करणार असलेल्या फील्डचे दस्तऐवज वाचा, आणि ते तीन प्रकारांपैकी कोणते आहे ते नोंदवा।

इतर टप्पे अजिबात टाइमर नाहीत। पुनर्जोडणीचा मागेपुढेपणा, परस्परसंवादी प्रमाणीकरण सूचना किंवा फक्त पुनर्संचयितीवर आपली संरचना पुन्हा मूल्यांकन करणारा क्लायंट — यापैकी प्रत्येकजण खंडावर वर्चस्व गाजवू शकतो, तर प्रत्येक प्रोटोकॉल टाइमर आरामात खाली बसलेला असतो।

प्रत्यक्षात संथ असलेला टप्पा मोजा

अपयश एकदाच पकडा, दोन्ही बाजूंना वेळ-शिक्क्यांसह, नंतर प्रोटोकॉलच्या स्वतःच्या काउंटरऐवजी चार घटनांची तुलना करा। योग्यरित्या केलेली एक निरीक्षण खिडकी एका महिन्याच्या ट्यूनिंगपेक्षा चांगली आहे।

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

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

पर्याय आधीच उपयुक्त असला पाहिजे

संरचनेत परिभाषित केलेला बॅकअप हा कार्यरत बॅकअप नसतो। तो क्लायंटच्या सध्याच्या नेटवर्कमधून पोहोचण्यायोग्य असला पाहिजे, तीच ओळख प्रमाणित करू शकला पाहिजे, आणि त्याच धोरणानुसार तीच रहदारी वाहून नेण्यास परवानगी असली पाहिजे। खंडादरम्यान या तीनपैकी कोणतीही त्रुटी आढळल्यास टाइमरची चर्चा अप्रासंगिक होते। प्राथमिक निरोगी असताना पर्यायाची चाचणी करा, कारण दोन्ही लॉग शेजारीशेजारी वाचता येण्याची तीच एकमेव वेळ आहे।

पर्याय आगाऊ तयार ठेवा, प्राथमिक निरोगी असताना जाणीवपूर्वक त्याची चाचणी करा, आणि चारपैकी कोणता टप्पा वेळ घेतो ते नोंदवा। तीच नोंद पुढील बदलाला अंदाजाऐवजी मापन बनवते।

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

प्राथमिक पुनर्संचयित करणे हा वेगळा निर्णय आहे। आक्रमक फेलबॅक बॅकअपवर आधीच पुनर्प्राप्त झालेले काम व्यत्यय आणू शकतो, आणि खरा दोष दोन समान पर्यायांमध्ये सतत डोलणारा मार्ग असताना डोलणारा मार्ग अस्थिर बोगद्यासारखा दिसू शकतो।

प्राधान्य नसलेले दोन समान-खर्चाचे मार्ग दृश्यमान डोलण्याचा नेहमीचा स्रोत आहेत, कारण प्रत्येक मॉनिटर दुसऱ्याच्या निवडीवर प्रतिक्रिया देतो। सामान्य परिस्थितीत कोणता मार्ग पसंतीचा आहे ते ठरवा, आणि ते प्राधान्य मार्ग क्रमावर सोडण्याऐवजी संरचनेत स्पष्ट करा। इच्छित फेलबॅक वर्तन आणि त्याचा मालक कोण आहे हे आगाऊ परिभाषित करा। मागील सेटिंग्ज आणि स्वतंत्र व्यवस्थापन मार्ग ठेवा, कारण खंडादरम्यान तुमचा स्वतःचा प्रवेश काढून टाकणारा बदल नेटवर्क घटनेला साइट भेटीत बदलतो।

नंतर तोच कार्यभार पुन्हा करा आणि तेच चार वेळ-शिक्के तुलना करा। तोच गहाळ मार्ग किंवा लॉगिन अनुप्रयोगाला अजूनही वाट पाहायला लावणारी लहान पुनर्प्राप्ती प्रगती नाही, ती त्याच आलेखावरील वेगळी संख्या आहे।