साइट टनेल फर्किएपछि फलब्याक लिज: नवीकरण गर्ने कि पर्खने?
पुनर्स्थापित साइट टनेल र ग्राहकको अस्थायी लिज दुई घडी हुन्। जबरजस्ती नवीकरणको पर्खाइसँग तुलना गर्नुहोस्, र वास्तवमा कुन सर्भरले जवाफ दियो पढ्नुहोस्।
साइट लिंक सक्रिय छ, टनेल स्थापित छ, तर शाखाका कम्प्युटरहरू अझै फाइल सर्भरसम्म पुग्न सक्दैनन्। अवरोधका क्रममा दुई घडी चलिरहेका थिए र तीमध्ये एउटा मात्र सकिएको छ। इन्क्रिप्टेड बाटो फर्किएपछि टनेल पुनर्स्थापित भयो; प्रत्येक ग्राहकको ठेगाना उसको हालको लिज सकिँदा वा प्रतिस्थापित हुँदा पुनर्स्थापित हुन्छ। ती दुई समयरेखाको तुलनाले फायरवाल लग पढ्नुभन्दा छिटो अन्तर व्याख्या गर्छ।
दुई घडी, र तीमध्ये एउटा टनेल होइन
VPN माथि DHCP र स्थानीय फलब्याकसँग, टाढाको DHCP बाटो उपलब्ध नभएको बेला उपकरणले अस्थायी स्थानीय लिज दिन सक्छ। अस्थायी अवधि सामान्यतया मिनेटमा गनिन्छ, जो समस्या लुकाउन पर्याप्त छोटो र छोटो अवरोध पार गर्न पर्याप्त लामो हुन्छ। टनेल फर्किएपछि फलब्याक ती लिज दिन बन्द गर्छ। यसले ग्राहकभित्र पसेर उसले पहिले नै राखेको लिज रद्द गर्दैन। त्यो ग्राहकले आफ्नो ठेगाना, मास्क, गेटवे र रिजोल्भर नवीकरण वा समाप्तिसम्म राख्छ, र त्यसैले स्वस्थ टनेल र बिग्रिएको डेस्कटप लिजको बाँकी समयसम्म सँगै रहन सक्छन्।
कार्यान्वयन र सफ्टवेयर संस्करणलाई यो भनाइसँग जोडेर राख्नुहोस्। टाइमरका नाम र पूर्वनिर्धारित मानहरू SonicOS संस्करणहरूबीच फरक हुन्छन्, र पुरानो इन्टरफेसले नयाँले के गर्छ भन्ने प्रमाणित गर्दैन।
दुई पुनर्स्थापना कदमको तुलना गर्नुहोस्
कदम A पर्खनु हो। यसको कुनै खर्च छैन, कुनै जोखिम छैन, र यसले प्रत्येक ग्राहकलाई आफ्नै तालिकाअनुसार नवीकरण गर्न दिन्छ। कदम B प्रभावित ग्राहकमा जबरजस्ती रिलिज र नवीकरण गर्नु हो, जसले इच्छित ठेगाना तुरुन्तै दिन्छ तर ग्राहकले गरिरहेको सबै काम अवरुद्ध गर्छ। एउटै डेस्कटपमा, जबरजस्ती नवीकरण सामान्यतया छिटो बाटो हो र यसलाई न्यायोचित ठहराउन सजिलो छ। प्रयोगशालामा वा कारोबारको बीचमा रहेको बिक्री टर्मिनलमा पर्खनु सुरक्षित विकल्प हो, र कामको समयबाहिर तालिका बनाइएको नवीकरण दुवैलाई जित्छ।
ipconfig /all
ipconfig /release
ipconfig /renew
केही रिलिज गर्नुअघि आउटपुट पढ्नुहोस्। यदि ठेगाना, गेटवे र DNS पहिले नै सामान्य दायरासँग मेल खान्छ भने, ग्राहक आफैँ पुनर्स्थापित भएको छ र बाँकी समस्या अन्यत्र छ। Linux ग्राहकमा समान कुरा हातले सम्पादित ठेगाना होइन, नेटवर्क म्यानेजरमार्फत लिज रिलिज र नवीकरण हो, किनभने अन्यथा म्यानेजरले अर्को घटनामा तपाईंको परिवर्तन फेरि लेख्नेछ।
प्रस्ताव पढ्नुहोस्, ठेगाना मात्र होइन
ठेगानाले मात्र यो कसले दियो भन्ने बताउँदैन। महत्त्वपूर्ण कुरा प्रस्तावमा रहेको सर्भर पहिचानकर्ता, लिजको समय, र गेटवे तथा रिजोल्भर फलब्याक दायरासँग मिल्छ कि सामान्यसँग भन्ने हो।
tcpdump -ni any 'port 67 or port 68'
नवीकरणका क्रममा क्याप्चर गर्नुहोस्, किनभने शान्त इन्टरफेसले ग्राहकले कहिल्यै नमागेको कुरा बताउँछ। टनेल सक्रिय हुँदा प्रस्ताव स्थानीय फलब्याकबाट आयो भने, छनोट तर्कले टाढाको बाटोलाई अझै अनुपलब्ध मानिरहेको छ, र ग्राहकहरूमा जबरजस्ती नवीकरणले त्यही नतिजा दोहोर्याउनेछ। क्याप्चरलाई उही घडीमा टनेल घटनाहरूसँग सहसम्बन्धित गर्नुहोस्। ग्राहकको अनुरोधभन्दा सेकेन्डअघि सकिने कुञ्जी-नवीकरण वा छोटो खस्किनु सम्भावित कारण हो; सफा टनेलसँग फलब्याक उत्तर छनोट बाटोमा कन्फिगरेसन समस्या हो।
जहाँ तुलना उल्टिन्छ
यदि एकैचोटि धेरै ग्राहक प्रभावित भए, प्रति-ग्राहक नवीकरण अवरोधको लाइन र सहयोग कलमा परिणत हुन्छ। त्यस्तो अवस्थामा ग्राहकहरूलाई होइन, फलब्याक दायरा र पुनर्स्थापना प्रक्रियालाई हेर्नुहोस्, किनभने त्यो समूह सँगै पुनर्स्थापित भयो र फेरि सँगै पुनर्स्थापित हुनेछ।
यदि छिमेकीहरू ठीक हुँदा एउटा ग्राहक मात्र प्रभावित भयो भने, उल्टो सत्य हो: त्यो ग्राहकको लिज, उसको आरक्षण वा उसको आफ्नै DHCP ग्राहकको व्यवहार परिवर्तनशील हो, र सम्पूर्ण साइटमा परिवर्तन गलत औजार हो।
स्थिर ठेगाना र आरक्षणलाई तेस्रो उत्तर चाहिन्छ। ठेगानामा पिन गरिएको ग्राहकलाई नवीकरणले बचाउन सकिँदैन, र फलब्याक दायरासँग ठोक्किने आरक्षणले दुईवटा ठेगाना योजना तुलना नगरेसम्म राउटिङ खराबीजस्तो देखिने प्रतिलिपि बनाउँछ।
बाहिर निस्कने प्रक्रिया लेख्नुहोस्
फलब्याक केका लागि हो, ग्राहकले आफ्नो अस्थायी ठेगाना कति समय राख्न सक्छ, र कामको समयमा कसले नवीकरण जबरजस्ती गर्न पाउँछ भन्ने अग्रिम निर्णय गर्नुहोस्। उत्तर त्यहाँ लेख्नुहोस् जहाँ ड्युटीमा खटिएको इन्जिनियरले भेट्टाउन सक्छ, दायराको परिभाषाको छेउमा। त्यसपछि एकचोटि जानाजान परीक्षण गर्नुहोस्: टनेल खसाल्नुहोस्, ग्राहकले के प्राप्त गर्छ हेर्नुहोस्, टनेल पुनर्स्थापित गर्नुहोस्, र ग्राहकले आफ्ना सामान्य सेटिङ फर्काउन कति समय लिन्छ लेख्नुहोस्। त्यो एउटै अभ्यासले अर्को पटक साइट लिंक डगमगाउँदा धेरै अनुमानको ठाउँ लिन्छ।
स्रोतको पुष्टि गरेर टुङ्ग्याउनुहोस्, ठेगानाको होइन। फाइल सर्भरसम्म पुग्नु, उसको नाम समाधान गर्नु र इन्टरनेटसम्म पुग्नु तीन अलग जाँच हुन्, र अन्तिममा मात्र कहिल्यै शंका थिएन।