साइट टनल परत आल्यानंतर फॉलबॅक लीज: नूतनीकरण करायचे की थांबायचे?

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

दोन घड्याळे, आणि त्यांपैकी एक टनल नाही

VPN वरून DHCP आणि स्थानिक फॉलबॅकसह, दूरचा DHCP मार्ग उपलब्ध नसताना उपकरण तात्पुरत्या स्थानिक लीज देऊ शकते. तात्पुरता कालावधी सहसा मिनिटांत मोजला जातो, जो समस्या लपवण्यासाठी पुरेसा लहान आणि थोडक्यात बिघाड टिकून राहण्यासाठी पुरेसा मोठा असतो. टनल परत आल्यावर फॉलबॅक त्या लीज देणे थांबवतो. तो क्लायंटच्या आत जाऊन त्याच्याकडे आधीच असलेली लीज रद्द करत नाही. तो क्लायंट त्याचा पत्ता, मास्क, गेटवे आणि रिझॉल्व्हर नूतनीकरण किंवा समाप्तीपर्यंत ठेवतो, आणि म्हणून निरोगी टनल व बिघडलेला डेस्कटॉप लीजच्या उर्वरित काळात एकत्र राहू शकतात.

अंमलबजावणी आणि सॉफ्टवेअर आवृत्ती या विधानाशी जोडून ठेवा. टाइमरची नावे आणि डीफॉल्ट मूल्ये SonicOS आवृत्त्यांमध्ये वेगळी असतात, आणि जुना इंटरफेस नवीन काय करतो हे सिद्ध करत नाही.

दोन पुनर्प्राप्ती पायऱ्यांची तुलना करा

पायरी A म्हणजे थांबणे. त्याला काहीही खर्च नाही, काहीही धोका नाही, आणि तो प्रत्येक क्लायंटला त्याच्या स्वतःच्या वेळापत्रकानुसार नूतनीकरण करू देतो. पायरी B म्हणजे बाधित क्लायंटवर सक्तीचे प्रकाशन आणि नूतनीकरण करणे, जे इच्छित पत्ता लगेच देते पण क्लायंट जे काही करत आहे ते सर्व व्यत्ययित करते. एका डेस्कटॉपवर सक्तीचे नूतनीकरण सहसा वेगवान मार्ग असतो आणि ते समर्थनीय ठरवणे सोपे आहे. प्रयोगशाळेत किंवा व्यवहाराच्या मध्यभागी असलेल्या पॉइंट-ऑफ-सेल टर्मिनलवर थांबणे ही सुरक्षित निवड आहे, आणि कामाच्या वेळेबाहेर नियोजित नूतनीकरण दोन्हींना मागे टाकते.

ipconfig /all
ipconfig /release
ipconfig /renew

काहीही प्रकाशित करण्यापूर्वी आउटपुट वाचा. जर पत्ता, गेटवे आणि DNS आधीच सामान्य श्रेणीशी जुळत असतील, तर क्लायंटने स्वतः पुनर्प्राप्ती केली आहे आणि उर्वरित समस्या अन्यत्र आहे. Linux क्लायंटवर समतुल्य गोष्ट म्हणजे हाताने संपादित पत्ता नाही, तर नेटवर्क व्यवस्थापकाद्वारे लीज प्रकाशन आणि नूतनीकरण, कारण अन्यथा व्यवस्थापक पुढील घटनेत तुमचा बदल पुन्हा लिहील.

ऑफर वाचा, फक्त पत्ता नाही

पत्ता एकटाच तो कोणी दिला हे सांगत नाही. महत्त्वाचे म्हणजे ऑफरमधील सर्व्हर ओळखकर्ता, लीजची वेळ, आणि गेटवे व रिझॉल्व्हर फॉलबॅक श्रेणीशी जुळतात की सामान्यशी.

tcpdump -ni any 'port 67 or port 68'

नूतनीकरणाच्या वेळी कॅप्चर करा, कारण शांत इंटरफेस तुम्हाला सांगते की क्लायंटने कधीही मागणी केली नाही. टनल सुरू असताना ऑफर स्थानिक फॉलबॅकमधून आली तर निवडीचे तर्क दूरचा मार्ग अजूनही अनुपलब्ध मानत आहे, आणि क्लायंटवर सक्तीचे नूतनीकरण केवळ तोच निकाल पुन्हा देईल. कॅप्चर त्याच घड्याळावरील टनल घटनांशी सहसंबंधित करा. क्लायंटच्या विनंतीच्या काही सेकंद आधी संपणारे की-नूतनीकरण किंवा थोडक्यात खंड हे संभाव्य कारण आहे; स्वच्छ टनलसह फॉलबॅक उत्तर ही निवडीच्या मार्गातील कॉन्फिगरेशन समस्या आहे.

जिथे तुलना उलटते

अनेक क्लायंट एकाच वेळी बाधित झाले तर प्रति-क्लायंट नूतनीकरणे व्यत्ययांची रांग आणि सहाय्यता कॉलमध्ये बदलतात. त्या स्थितीत क्लायंटऐवजी फॉलबॅक श्रेणी आणि पुनर्संचयन प्रक्रिया पाहा, कारण तो समूह एकत्र पुनर्प्राप्त झाला आहे आणि पुन्हा एकत्र पुनर्प्राप्त होईल.

शेजारी ठीक असताना केवळ एक क्लायंट बाधित झाला असेल तर उलटे खरे आहे: त्या क्लायंटची लीज, त्याचे आरक्षण किंवा त्याच्या स्वतःच्या DHCP क्लायंटचे वर्तन हे चल आहे, आणि संपूर्ण साइटवरील बदल हे चुकीचे साधन आहे.

स्थिर पत्ते आणि आरक्षणांना तिसरे उत्तर हवे आहे. पत्त्यावर पिन केलेल्या क्लायंटला नूतनीकरणाने वाचवता येत नाही, आणि फॉलबॅक श्रेणीशी टकरणारे आरक्षण अशी प्रत तयार करते जी दोन्ही पत्ता योजना तुलना करेपर्यंत राउटिंग बिघाडासारखी दिसते.

बाहेर पडण्याची प्रक्रिया लिहा

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

संसाधनाची पुष्टी करून समाप्त करा, पत्त्याची नाही. फाइल सर्व्हरपर्यंत पोहोचणे, त्याचे नाव सोडवणे आणि इंटरनेटपर्यंत पोहोचणे ही तीन वेगळी तपासणी आहेत, आणि केवळ शेवटच्याबद्दल कधीही शंका नव्हती.