DHCP नवीकरणपछि VPN खस्छ? ठेगानाहरू तुलना गर्नुहोस्
नवीकरणले सामान्यतया उही ठेगाना राख्छ। लिजलाई दोष दिनुअघि खसाइको वरपर क्लाइन्टको ठेगाना, गेटवे, रिजोल्भर र रुटको अवस्था जाँच्नुहोस्।
लिज नवीकरण र VPN असफलता लगमा पटक-पटक सँगै देखिन्छन्, जसले गर्दा मानिसहरू एउटाले अर्कोलाई निम्त्याउँछ भन्ने निष्कर्षमा पुग्छन्। समयको मेल साँचो हो; कारणसम्बन्ध सामान्यतया होइन। नवीकरण भनेको लिज दिने सर्भरलाई गरिएको युनिकास्ट अनुरोध हो, त्यही बाइन्डिङ प्रयोग गर्न जारी राख्न अनुरोध गर्दै, र सर्भरले क्लाइन्टले एउटै ठेगाना नबदली त्यसलाई लम्ब्याउन सक्छ। घटनाको वरपर क्लाइन्टका आफ्नै मानहरू हेर्दा चुपचाप नवीकृत भएको लिज र चालु टनेलमुनि साँच्चै परिवर्तन भएको नेटवर्क छुट्याइन्छ।
खसेको क्लाइन्टबाट सुरु गर्नुहोस्
पहिले क्लाइन्टको जडान लग खोल्नुहोस् र खसाइको समय सेकेन्डसम्म लेख्नुहोस्। त्यसपछि त्यही मिनेटको लागि अपरेटिङ सिस्टमको नेटवर्क लग खोल्नुहोस् र इन्टरफेसले के गर्यो भनेर क्रममा पढ्नुहोस्। यही क्रम नै सम्पूर्ण अनुसन्धान हो: डिस्कनेक्ट अघिको DHCP घटना, DHCP घटना अघिको डिस्कनेक्ट, र बीचमा केही नभएका दुई घटना तीन फरक निष्कर्ष हुन्। टनेल पहिले नै फेरि जोडिँदै गर्दा केवल लिजको उल्लेख गर्ने लग लाइन सजावट हो, प्रमाण होइन।
समयरेखा सम्झनामा राख्नुको सट्टा हिँड्दै लेख्नुहोस्। फरक-फरक उपकरणका टाइमस्ट्याम्प विरलै पूर्ण मिल्छन्, र त्यो भिन्नता नै कहिलेकाहीँ व्याख्या हुन्छ।
घटनाको वरपरका चार मान तुलना गर्नुहोस्
चार मानले जडानको स्थानीय पक्षलाई साँचो परिवर्तन समात्न पर्याप्त राम्ररी वर्णन गर्छन्: इन्टरफेसको ठेगाना, पूर्वनिर्धारित गेटवे, रिजोल्भर सूची र इन्टरफेसको सञ्चालन अवस्था। खसाइको एक मिनेटभित्र ती लिनुहोस् र टनेल स्वस्थ हुँदा लिइएको क्याप्चरसँग तुलना गर्नुहोस्।
ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcpअपरिवर्तित ठेगाना, अपरिवर्तित गेटवे र परिवर्तित रिजोल्भर सूचीले रुटिङतर्फ होइन, नाम-समाधानतर्फ संकेत गर्छ, र अनुप्रयोगहरूले होस्ट खोज्न छाड्दा टनेल बाँचेको हुन सक्छ। परिवर्तित गेटवेको अर्थ स्थानीय नेटवर्कबाट बाहिर जाने बाटो सर्यो भन्ने हो, र त्यो अघिल्लोतर्फ देखाउने रुट अमान्य गर्न पर्याप्त छ। यदि चारै मान स्वस्थ क्याप्चरसँग मिल्छन् भने लिज तपाईंको कारण होइन र क्लाइन्टको आफ्नै पुनःजडान तर्क विषय बन्छ। त्रुटि देखिने बेलामै तुलना लिनुहोस्, किनकि रिबुटपछि लिइएको स्वस्थ क्याप्चरको ठेगाना-इतिहास फरक हुन्छ र मिल्ने छैन।
नवीकरणले के बदल्न सक्छ र के सक्दैन
RFC 2131 ले नवीकरणलाई लिज समयको आधामा मूल सर्भरमा गरिने अनुरोधका रूपमा वर्णन गर्छ, र पहिलो प्रयास उत्तर नपाई रहे आठमध्ये सात भागमा कुनै पनि सर्भरसँग पुनः बाइन्डिङका रूपमा। दुवै चरणले क्लाइन्टले फरक ठेगाना लिनुपर्ने माग गर्दैनन्, र सहयोगी सर्भरले सामान्यतया विद्यमान बाइन्डिङ लम्ब्याउँछ। साँचो ठेगाना परिवर्तन सामान्यतया अर्को बाटोबाट आउँछ: सर्भरले नवीकरण अस्वीकार गर्छ, क्लाइन्टले आफ्नो अवस्था गुमाएर फेरि सुरु गर्छ, वा नेटवर्कले उपकरण अर्को खण्डमा सार्छ।
जडानको सार्वजनिक पक्ष कुनै पनि स्थानीय परिवर्तन बिना बदलिन सक्छ। क्यारियर-ग्रेड अनुवादपछाडि VPN सहकर्मीले देख्ने ठेगाना स्थानीय लिजले गरेको कुनै पनि कुरासँग सम्बन्ध नराखी पुनः तोकिन सक्छ, र त्यो पुनःतोकाइ क्लाइन्टभित्रबाट स्थानीय नेटवर्क असफलताजस्तै देखिन्छ। स्थानीय रूपमा जनाइएको ठेगानाको सहकर्मी-पक्षको अवलोकनसँग तुलना गर्नु नै तिनलाई छुट्याउने एकमात्र उपाय हो।
क्लाइन्ट अनुकूलन हुन नसक्दा
जसले आफ्नो यातायात पुरानो ठेगानामा बाँध्यो, सहकर्मीतर्फ पुरानो रुट क्यास गर्यो वा इन्टरफेस पहिचान सुरक्षित राख्यो, त्यो अब नभएको बाटोमा फेरि-फेरि प्रयास गर्न सक्छ। त्यो अनुकूलन दोष हो, र होस्टले अब पुग्न नसक्ने ठेगानातर्फ बारम्बार पुनःप्रेषणका रूपमा देखिन्छ। केही क्लाइन्टले यसलाई रचनाअनुसारै सम्हाल्छन्: उदाहरणका लागि WireGuard ले नयाँ स्रोतबाट राम्ररी प्रमाणित प्याकेट आएपछि सहकर्मीको अन्त्य बिन्दु अद्यावधिक गर्छ।
सेवा फर्काउने म्यानुअल रिस्टार्ट अनुकूलन कहाँ असफल भयो भन्ने संकेत हो, लिज र टनेल असंगत छन् भन्ने प्रमाण होइन। परीक्षणका क्रममा अवरोध नीति लागू राख्नुहोस्, नत्र परीक्षण आफैँ अर्को कारणको अवरोध बन्छ। क्लाइन्ट आफैँ सुधारियो कि, कति समय लाग्यो र कुन ठेगानामा फेरि प्रयास गर्यो लेख्नुहोस्; त्यो क्रमले इन्टरफेसमा देखाइएको डिस्कनेक्ट कारणभन्दा बढी बताउँछ।
दोष दिनुअघि घटना दोहोर्याउनुहोस्
तालिका पर्खनुको सट्टा अवस्था पुनःउत्पादन गर्नुहोस्: लिज छोडेर फेरि नवीकरण गर्नुहोस्, वा समतुल्य नियन्त्रित घटना जबरजस्ती गराउनुहोस्, र टनेल बाँच्छ कि हेर्नुहोस्। व्यवस्थापित नेटवर्कमा ठेगानाको कुनै पनि परिवर्तन नेटवर्क मालिकसँग समन्वय गर्नुहोस्, किनकि स्वेच्छाचारी स्थिर बाँडफाँट त्यो ठेगाना पहिले नै भएको उपकरणसँग ठोक्किन सक्छ।
समर्थित सुधारपछि त्यही घटना दोहोर्याउनुहोस् र त्यसपछि एउटा अनुप्रयोग र नाम-खोज परीक्षण गर्नुहोस्, किनकि फेरि जोडिने तर DNS तोड्ने टनेल महत्त्वपूर्ण परीक्षणभन्दा कमजोर परीक्षणमा उत्तीर्ण हुन्छ। तालिकाबद्ध लिजलाई कारण भन्नुको सट्टा तपाईंले देख्नुभएको विशिष्ट परिवर्तन त्यसको टाइमस्ट्याम्पसहित जनाउनुहोस्। यी दुई प्रतिवेदनबीचको फरक भनेको अर्को व्यक्तिले त्रुटि पुनःउत्पादन गर्न सक्छ कि केवल हल्ला।