साइट टनल लौटने के बाद फ़ॉलबैक लीज़: नवीनीकरण करें या प्रतीक्षा करें?

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

दो घड़ियाँ, और उनमें से एक टनल नहीं है

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

कार्यान्वयन और सॉफ़्टवेयर संस्करण को इस कथन से जोड़े रखें। टाइमर के नाम और डिफ़ॉल्ट मान SonicOS संस्करणों में भिन्न होते हैं, और पुराना इंटरफ़ेस यह सिद्ध नहीं करता कि नया क्या करता है।

दो रिकवरी क़दमों की तुलना करें

क़दम A है प्रतीक्षा करना। इसमें कोई ख़र्च नहीं, कोई जोखिम नहीं, और यह हर क्लाइंट को उसके अपने समय-चक्र पर नवीनीकरण करने देता है। क़दम B है प्रभावित क्लाइंट पर ज़बरदस्ती रिलीज़ और नवीनीकरण करना, जो इच्छित पता तुरंत देता है पर क्लाइंट जो कुछ कर रहा है उसे बाधित करता है। एक ही डेस्कटॉप पर ज़बरदस्ती नवीनीकरण आमतौर पर तेज़ रास्ता है और इसे उचित ठहराना आसान है। लैब में या लेन-देन के बीच में पड़े पॉइंट-ऑफ़-सेल टर्मिनल पर प्रतीक्षा सुरक्षित विकल्प है, और काम के घंटों के बाहर निर्धारित नवीनीकरण दोनों से बेहतर है।

ipconfig /all
ipconfig /release
ipconfig /renew

कुछ भी रिलीज़ करने से पहले आउटपुट पढ़ें। अगर पता, गेटवे और DNS पहले से सामान्य परिसर से मेल खाते हैं, तो क्लाइंट ने स्वयं रिकवर कर लिया है और बाक़ी समस्या कहीं और है। Linux क्लाइंट पर समतुल्य कार्य नेटवर्क मैनेजर के ज़रिए लीज़ रिलीज़ और नवीनीकरण है, हाथ से संपादित पता नहीं, क्योंकि वरना मैनेजर अगली घटना पर आपका बदलाव फिर से लिख देगा।

प्रस्ताव पढ़ें, केवल पता नहीं

पता अकेला यह नहीं बताता कि उसे किसने दिया। महत्वपूर्ण है प्रस्ताव में सर्वर पहचानकर्ता, लीज़ का समय, और यह कि गेटवे तथा रिज़ॉल्वर फ़ॉलबैक परिसर से मेल खाते हैं या सामान्य से।

tcpdump -ni any 'port 67 or port 68'

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

जहाँ तुलना उलट जाती है

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

अगर केवल एक क्लाइंट प्रभावित हो जबकि उसके पड़ोसी ठीक हों, तो उलटा सच है: उस क्लाइंट की लीज़, उसका आरक्षण या उसके अपने DHCP क्लाइंट का व्यवहार चर है, और पूरी साइट में बदलाव ग़लत औज़ार है।

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

निकास प्रक्रिया लिखें

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

संसाधन की पुष्टि करके समाप्त करें, पते की नहीं। फ़ाइल सर्वर तक पहुँचना, उसका नाम हल करना और इंटरनेट तक पहुँचना तीन अलग जाँचें हैं, और केवल अंतिम पर कभी संदेह नहीं था।