VPN जोडलेले आहे पण नावे अयशस्वी होतात: DNS प्रत्यक्षात कुठे तुटते

बोगदा वर आहे, चिन्ह हिरवे आहे आणि ब्राउझरचे प्रत्येक टॅब नाव-निराकरणाची अयशस्वीता नोंदवत आहे। हे चित्र तीन वेगळ्या यंत्रणा तयार करतात: रिझोल्व्हर पोहोचेल्या बाहेर असू शकतो, क्लायंट अपेक्षा न केलेल्या रिझोल्व्हरला विचारत असू शकतो, किंवा फक्त खाजगी नावे अयशस्वी होऊ शकतात। बोगदा प्रोटोकॉलमध्ये काहीही बदलण्यापूर्वी हे वेगळे करा, कारण प्रत्येकाची दुरुस्ती वेगळ्या ठिकाणी होते। खालील क्रम तिन्ही वेगळे करणार्या निरीक्षणांपासून सुरू होतो।

शोधाला प्रत्यक्षात काय आवश्यक आहे

शोधाला तीन गोष्टी आवश्यक आहेत: रिझोल्व्हरचा पत्ता, त्या पत्त्यापर्यंतचा मार्ग आणि प्रश्नाशी जुळणारे उत्तर। प्रत्येक स्वतंत्रपणे अयशस्वी होऊ शकते, आणि दिसणारे लक्षण म्हणजे न लोड होणारे तेच पान। म्हणून तिन्हींपैकी काय तुटले हे कळण्यापूर्वी त्रुटी पान तुम्हाला जवळपास काहीही सांगत नाही।

क्लायंट आपला रिझोल्व्हर VPN प्रोफाइलमधून, बोगद्यावरील DHCPमधून किंवा स्वतःच्या संरचनेतून शिकतो, आणि कोणता स्रोत जिंकेल हे प्लॅटफॉर्मवर अवलंबून असते। Windows वर, ipconfig /all प्रत्येक अ‍ॅडॉप्टरसाठी DNS सर्व्हर दाखवते, त्यामुळे पाठवलेले मूल्य प्रत्यक्षात पोहोचले का हे तुम्ही पाहू शकता। ऑपरेटिंग सिस्टमपर्यंत कधीही न पोहोचलेले पाठवलेले मूल्य ही शांत आणि सामान्य अयशस्वीता आहे। प्रोफाइलला हात लावण्यापूर्वी संरचित मूल्य वाचा।

Linux आणि macOS त्याच प्रश्नाचे उत्तर वेगळ्या आदेशांनी देतात, आणि उत्तर त्याच वाचनास पात्र आहे: resolvectl status आणि scutil --dns दोन्ही प्रत्येक इंटरफेससाठी सर्व्हर सूचीबद्ध करतात। ती यादी प्रोफाइल पाठवतो असे दावा करणार्या पत्त्याशी तुलना करा। येथील विसंगती खालील सर्व गोष्टी स्पष्ट करते, म्हणून नावे तपासण्यापूर्वी ती सोडवा।

एक सार्वजनिक आणि एक खाजगी नाव तपासा

एक सामान्य सार्वजनिक होस्टनाव आणि दस्तऐवजीकृत खाजगी होस्टनाव त्याच मशीनवरून विचारा आणि कोणत्या सर्व्हरने कोणाला उत्तर दिले ते लिहा। दोन्ही अयशस्वी झाल्यास रिझोल्व्हर किंवा त्याचा मार्ग तुटलेला आहे। फक्त खाजगी नाव अयशस्वी झाल्यास रिझोल्व्हरने उत्तर दिले आहे आणि प्रश्न झोन किंवा मार्गनिर्देशन होतो। मार्ग बदलामुळे फरक स्पष्ट होऊ नये म्हणून दोन्ही प्रश्न एका मिनिटाच्या आत चालवा।

अंतर्गत नावे सार्वजनिक स्क्रीनशॉटपासून आणि सार्वजनिक रिझोल्व्हरपासून दूर ठेवा। कालबाह्यता आणि अस्तित्वात नसलेल्या डोमेनचे उत्तर वेगळी निरीक्षणे आहेत: पहिले सांगते की काहीही परत आले नाही, दुसरे सांगते की एका प्राधिकार्याने उत्तर दिले की नाव अस्तित्वात नाही। दोन्हींना एकच त्रुटी मानल्यास तुम्ही चुकीच्या स्तरावर जाता, आणि प्रमाणपत्राची चेतावणी पुन्हा तिसरी गोष्ट आहे, DNS अयशस्वीता नाही।

nslookup ज्या सर्व्हरला विचारले आणि जे उत्तर मिळाले दोन्ही छापते, आणि तीच तुम्हाला आवश्यक असलेली जोडी आहे। ते त्याच शेलमध्ये दोन वेळा चालवा आणि प्रत्येक उत्तराजवळ उत्तर देणारा पत्ता लिहा।

nslookup example.com
nslookup host.corp.example 10.20.30.53

क्लायंट प्रत्यक्षात त्या सर्व्हरपर्यंत पोहोचू शकतो याची खात्री करा

प्रोफाइलने पाठवलेला खाजगी रिझोल्व्हर तेव्हाच उपयुक्त आहे जेव्हा बोगदा वर असताना क्लायंट त्याच्यापर्यंत पोहोचू शकेल। बरोबर दिसणारा पत्ता मार्गाशिवाय कालबाह्यता निर्माण करतो, आणि बोगद्याची जोडलेली स्थिती त्या मार्गाबद्दल काहीही सांगत नाही। तपासणी म्हणजे रिझोल्व्हरकडेच लक्ष्यित मार्ग शोध, VPN अंतबिंदूकडे नाही।

प्रत्येक प्लॅटफॉर्म त्याचे उत्तर एका ओळीत देते, आणि आउटपुटमध्ये नमूद केलेला इंटरफेस हे संपूर्ण उत्तर आहे। जर तो भौतिक अ‍ॅडॉप्टरकडे दाखवत असेल आणि रिझोल्व्हर बोगद्यामागे असेल, तर प्रोफाइल त्याला झाकणारा प्रीफिक्स पाठवत नाही।

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

विभाजित बोगदा प्रोफाइलमध्ये रिझोल्व्हर पाठवलेल्या मार्गांच्या बाहेर असू शकतो, ही सर्व्हरची नाही तर प्रोफाइलची समस्या आहे। रिझोल्व्हरचा पत्ता पाठवलेल्या प्रीफिक्सशी तुलना करा आणि त्यापैकी एक त्याला झाकतो याची खात्री करा। तीच विसंगती DNS एका नेटवर्कवर का चालते आणि समान प्रोफाइल असलेल्या दुसर्यावर का अयशस्वी होते हे स्पष्ट करते।

लक्षात ठेवा की ब्राउझर सिस्टम रिझोल्व्हरला बायपास करू शकतात

सुरक्षित DNS सुरू असलेला ब्राउझर आपल्या निवडीच्या पुरवठादाराकडे HTTPS वरून प्रश्न पाठवू शकतो आणि ऑपरेटिंग सिस्टमच्या रिझोल्व्हरकडे पूर्णपणे दुर्लक्ष करू शकतो। मग सिस्टम बरोबर दिसते पण ब्राउझर अयशस्वी होतो, किंवा उलट। हा बोगद्यासाठी नाही, ब्राउझरसाठी धोरणाचा प्रश्न आहे।

ब्राउझरची सुरक्षित-DNS सेटिंग आणि तिला नियंत्रित करणारे कोणतेही व्यवस्थापित धोरण तपासा, नंतर बोगदा बदलल्याशिवाय दुसरा अनुप्रयोग किंवा ब्राउझर वापरून पहा। फक्त एक अनुप्रयोग अयशस्वी झाल्यास दुरुस्ती त्या अनुप्रयोगातील आहे। खाजगी विंडो स्वच्छ तुलना नाही, कारण ती एका ब्राउझरमध्ये विस्तार डीफॉल्टने बंद करू शकते आणि दुसर्यात नाही, आणि ती कधीही व्यवस्थापित धोरणाला बायपास करत नाही। त्याऐवजी दुसरे ब्राउझर प्रोफाइल किंवा वेगळा अनुप्रयोग वापरा।

कॅशे रिकामा करा आणि खरे काम पुन्हा तपासा

सेटिंग दुरुस्त केल्यानंतर स्थानिक रिझोल्व्हर कॅशे रिकामा करा जेणेकरून जुने उत्तर दुरुस्तीपेक्षा जास्त जगणार नाही। थोड्या बरे झाल्यानंतर पुन्हा अयशस्वीता म्हणजे कारण अजूनही आहे, कॅशे रिकामा करणे अयशस्वी झाले असे नाही। तीन कॅशे वेगवेगळे असल्याने तुम्ही ज्या मशीनवर आहात त्याला जुळणारी ओळ निवडा।

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

नंतर कृत्रिम शोधाऐवजी मूळ कामाची पुनरावृत्ती करा, कारण वापरकर्त्याला महत्त्वाचे ते कामच आहे। एकदा पुन्हा कनेक्ट करा, जेणेकरून पुनर्तपासणी वापरकर्ता प्रत्यक्षात ज्या स्थितीत असेल ती झाकेल। Microsoft चे nslookup संदर्भ प्रश्नाच्या आर्ग्युमेंट्ससाठी ठेवण्यासारखे पान आहे।

जर नावे फक्त डिस्कनेक्ट केल्यानंतर अयशस्वी होत असतील, तर क्लायंटने मागील संरचना पुनर्संचयित केली नाही, ही DNS सर्व्हर बदलण्याऐवजी नोंदवण्यासारखी जीवनचक्रातील त्रुटी आहे। चालणारा शोधही गळती चाचणी नाही, कारण बाहेर पडणारा देश कोणत्या रिझोल्व्हरने उत्तर दिले हे सांगत नाही।