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 तोड़ने वाली टनल उस परीक्षण से कमज़ोर परीक्षण पास करती है जो मायने रखता है। अनुसूचित लीज़ को कारण बताने के बजाय आपने जो विशिष्ट बदलाव देखा उसे उसके टाइमस्टैम्प के साथ बताएँ। इन दो रिपोर्टों का अंतर यह है कि अगला व्यक्ति खराबी दोहरा सकता है या केवल अफ़वाह।