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 तोडणारा बोगदा महत्त्वाच्या चाचणीपेक्षा कमकुवत चाचणीत उत्तीर्ण होतो। नियोजित भाडेपट्ट्याला कारण म्हणण्याऐवजी तुम्ही पाहिलेला विशिष्ट बदल त्याच्या वेळमुद्रेसह कळवा। या दोन अहवालांतील फरक म्हणजे पुढील व्यक्ती दोष पुनरुत्पादित करू शकते की फक्त अफवा।