VPN ने माझा DNS बदलला का? आधी आणि नंतर तुलना करा
प्रोफाइल तुमच्या क्वेरी जाणीवपूर्वक हलवू शकते। VPN जोडण्यापूर्वी आणि नंतर रिझॉल्व्हर धोरण आणि प्रत्यक्ष उत्तराची तुलना करा, एक चल स्थिर ठेवून।
तुम्ही टनेल जोडता, खाजगी डॅशबोर्ड उघडता, आणि नाव अशा पत्त्यावर सोडवले जाते जो तुम्ही कधीही पाहिला नाही। किंवा उलट घडते: ब्राउझर काम करत राहतो, पण कमांड-लाइन साधन अचानक काहीही सोडवत नाही। दोन्ही निकाल एकाच बदलातून येतात, आणि लोक सामान्यतः हे VPN "स्वतःचे DNS वापरते" अशा एका वाक्याने समजावून सांगतात, जे डीबग करण्यासाठी किंवा पडताळण्यासाठी पुरेसे अचूक नाही। त्या वाक्यात दोन प्रश्न दडलेले आहेत: हे प्रोफाइल कोणत्या क्वेरी घ्यायचे आहे, आणि तुमच्या मशीनने त्या खरोखर त्याला दिलेल्या रिझॉल्व्हरकडे पाठवल्या का? त्या वेगळ्या ठेवणे हीच संपूर्ण पद्धत आहे, कारण त्या मिसळणारी चाचणी दोन्ही दिशांनी आत्मविश्वासाने चुकीचे उत्तर देते।
प्रोफाइल अजिबात रिझॉल्व्हर का देते
टनेलच्या आत, दूरच्या टोकाच्या मागील नावे सामान्यतः फक्त त्या नेटवर्कमध्ये असलेल्या पत्त्यांवर सोडवली जातात। corp.internal सारख्या खाजगी झोनला सार्वजनिक प्रतिनिधित्व नाही, त्यामुळे त्याला उत्तर देणारे रिझॉल्व्हर टनेलच्या आतून पोहोचण्यायोग्य असले पाहिजे। तोच यंत्रणा दुसऱ्या उद्देशासाठीही काम करते: जेव्हा क्वेरी अन्यथा तुमच्या ISP मधून बाहेर पडल्या असत्या, तेव्हा दूरच्या बाजूचे रिझॉल्व्हर क्वेरीला एन्क्रिप्टेड मार्गात ठेवते। म्हणूनच DNS सर्व्हरचा पत्ता कनेक्शनच्या धोरणाचा भाग म्हणून येतो, मशीनसाठी एकदा निवडलेली जागतिक सेटिंग म्हणून नाही।
पत्ता स्वतः काहीही ठरवत नाही। रिझॉल्व्हर तेव्हाच उत्तर देऊ शकते जेव्हा त्याकडे मार्ग असतो, आणि सर्वात सामान्य बिघाड म्हणजे फक्त टनेल सुरू असताना पोहोचण्यायोग्य रिझॉल्व्हर। टनेल पडले आणि धोरण राहिले, तेव्हा क्वेरी मार्ग नसलेल्या पत्त्याकडे जातात, आणि लक्षण स्वच्छ त्रुटी नसून वेळ संपणे असते। पुढील चाचणी निकाल वाचताना हा फरक महत्त्वाचा आहे, कारण वेळ संपल्याने लोक अशा वाहतूक सेटिंग्जकडे जातात ज्या कधीही सहभागी नव्हत्या।
उत्तरांची तुलना करण्यापूर्वी दोन रचनांची तुलना करा
पूर्ण टनेल आणि विभाजित DNS विरुद्ध अपेक्षा निर्माण करतात, आणि दोन्हीपैकी कोणतेही बिघाड नाही। पूर्ण टनेलअंतर्गत प्रत्येक क्वेरी प्रदात्याकडे किंवा कॉर्पोरेट रिझॉल्व्हरकडे जाऊ शकते, त्यामुळे जोडल्यानंतर सार्वजनिक नावे वेगळी उत्तर देणे अपेक्षित आहे। विभाजित DNS अंतर्गत फक्त सूचीबद्ध डोमेन खाजगी रिझॉल्व्हरकडे जातात, बाकी सर्व स्थानिक राहते; Windows मध्ये डोमेन सूची Name Resolution Policy Table मध्ये, macOS मध्ये DNS सेटिंग्जच्या जुळणाऱ्या डोमेनमध्ये, आणि systemd-resolved होस्टवर प्रत्येक लिंकच्या राउटिंग डोमेनमध्ये असते।
हेच पहिल्यांदा करायचे तुलन आहे, कारण कशाला बिघाड मानायचे हे ते ठरवते। विभाजित DNS मध्ये, नवीन रिझॉल्व्हरकडून उत्तर देणारे सार्वजनिक नाव तपासण्यास योग्य असते, तर योग्यरित्या उत्तर देणारे अंतर्गत नाव म्हणजे प्रणाली आपले काम करत आहे। पूर्ण टनेलमध्ये, अजूनही तुमच्या ISP रिझॉल्व्हरकडून उत्तर देणारे सार्वजनिक नाव ही विसंगती आहे। Microsoft चे VPN नाव निराकरणावरील दस्तऐवज या नियमांचा Windows क्रम वर्णन करते, जुळणारी धोरण नोंद अडॅप्टरच्या स्वतःच्या सर्व्हरपूर्वी कशी विचारात घेतली जाते हेही।
खोलीत तिसरे रिझॉल्व्हर देखील आहे जे विसरणे सोपे आहे। ब्राउझरचे सुरक्षित DNS स्वतः नावे सोडवते आणि टनेलने ऑपरेटिंग सिस्टमचे धोरण बदलल्यानंतरही उत्तर देत राहू शकते, त्यामुळे लोड होणारे पृष्ठ ब्राउझरचे रिझॉल्व्हर चालले हे सिद्ध करते, प्रोफाइल लागू झाले हे नाही। जर तुम्ही फक्त ब्राउझर दाखवते त्याची तुलना करत असाल, तर अर्धा वेळ तुम्ही चुकीचा स्तर तपासत आहात।
फक्त एका चलासह आधाररेषा नोंदवा
टनेल बदला। त्याच टप्प्यात नाव, साधन किंवा शोध प्रत्ययही बदलू नका। ज्याची विचारणा करण्यास तुम्हाला परवानगी आहे असे नाव निवडा, कोणते अनुप्रयोग वापरले ते नोंदवा, आणि परत आलेला पत्ता किंवा अचूक त्रुटी लिहा। Windows मध्ये Get-DnsClientServerAddress -AddressFamily IPv4 प्रत्येक अडॅप्टरचे सर्व्हर छापते आणि Get-DnsClientNrptPolicy धोरण नोंदी छापते; systemd-resolved असलेल्या Linux मध्ये resolvectl status प्रत्येक लिंकचे DNS सर्व्हर आणि राउटिंग डोमेन दाखवते; macOS मध्ये scutil --dns प्रणाली खरोखर अनुसरणारा रिझॉल्व्हर क्रम छापते।
नंतर क्लायंटच्या नेहमीच्या नियंत्रणांद्वारे जोडा आणि तंतोतंत तेच आदेश पुन्हा करा। पहिले आउटपुट लक्षात ठेवण्याऐवजी जतन करा, कारण तुलनाच संपूर्ण मुद्दा आहे आणि कॅशे रिकामी केल्यानंतर घेतलेले दुसरे वाचन आधीच वेगळे मापन आहे। जर आधाररेषा ब्राउझर समोर ठेवून घेतली असेल आणि जोडल्यानंतरची क्रिया टर्मिनलमध्ये होत असेल, तर तुम्ही दोन रिझॉल्व्हरची तुलना करत आहात, एका रिझॉल्व्हरच्या दोन अवस्थांची नाही।
स्पष्ट क्वेरी आणि अनुप्रयोग शोध या वेगळ्या चाचण्या आहेत
एका विशिष्ट सर्व्हरला विचारणे, nslookup name 10.20.0.1 किंवा dig @10.20.0.1 name ने, एकच गोष्ट सिद्ध करते: तुम्ही नाव दिलेला सर्व्हर त्याच्यापर्यंत पोहोचता तेव्हा उत्तर देतो। हे निवडीच्या तर्काला पूर्णपणे बगल देते, त्यामुळे प्रणाली या नावासाठी तो सर्व्हर निवडली असती का हे सांगू शकत नाही। नियुक्त रिझॉल्व्हर पोहोचण्यायोग्य आहे का हे तपासण्यासाठी याचा वापर करा, आणि धोरण तपासण्यासाठी याचा वापर करू नका।
स्थानिक रिझॉल्व्हरमधून केलेला शोध निवडीचा खरोखर वापर करतो। resolvectl query name तेच राउटिंग-डोमेन नियम चालतो आणि कोणत्या प्रोटोकॉलने उत्तर दिले ते कळवतो, Windows मध्ये Resolve-DnsName धोरण तक्ता आणि क्लायंट कॅशेतून जातो, आणि scutil --dns शोध अनुसरणारा क्रम दाखवतो। दोन्ही प्रकार चालवा आणि ते तुमच्या टिपणांमधील वेगळ्या स्तंभांत ठेवा। यशस्वी स्पष्ट क्वेरीच्या शेजारी अयशस्वी अनुप्रयोग शोध म्हणजे राउटिंग किंवा निवडीची समस्या आहे, काम करण्यास नकार देणारे रिझॉल्व्हर नाही।
कॅशे तुमच्या आणि उत्तराच्या मध्ये उभी असते। ऑपरेटिंग सिस्टम, स्थानिक स्टब रिझॉल्व्हर, ब्राउझर आणि ऋणात्मक कॅशे हे सर्व निकाल ठेवतात, त्यामुळे एकही पॅकेट मशीन सोडल्याशिवाय शोध यशस्वी होऊ शकतो। काहीही रिकामे करण्यापूर्वी निकाल नोंदवा: ipconfig /flushdns, resolvectl flush-caches किंवा macOS मध्ये sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder। या टप्प्यावर व्यापक नेटवर्क रीसेट वगळा, कारण ते तुम्ही अजून गोळा करत असलेला पुरावा नष्ट करते।
फरकाचा अर्थ काय
तुम्ही नोंदवलेल्या दोन ओळींची तुलना करा आणि एकही सेटिंगला हात लावण्यापूर्वी बदलाचे वर्गीकरण करा।
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
एक ओळ विशेष भर देण्यास पात्र आहे। सोडवले जाणारे नाव कार्यरत सेवा नाही, आणि DNS चे यश फक्त पत्ता सापडला असे सांगते। ते फॉरवर्डिंग, फायरवॉल नियम किंवा तुमचे खाते ही सेवा वापरू शकते का याबद्दल काहीही सांगत नाही, म्हणून बिघाड स्वतःहून निघून गेला असे गृहीत धरण्याऐवजी प्रत्यक्ष अनुप्रयोग तपासून पूर्ण करा।
आधाररेषा पुनर्संचयित करा आणि पडताळा
प्रक्रिया मारण्याऐवजी क्लायंटच्या स्वतःच्या नियंत्रणांद्वारे डिस्कनेक्ट करा, नंतर तेच तीन आदेश पुन्हा वाचा। प्रत्येक लिंकचे सर्व्हर, धोरण नोंदी आणि तुमच्या चाचणी नावाचे उत्तर आधी लिहिलेल्या आधाररेषेकडे परत आले पाहिजेत। स्वच्छ डिस्कनेक्टनंतर शिल्लक राहिलेली धोरण नोंद हा नोंदवण्यायोग्य खरा दोष आहे, आणि म्हणूनच निर्मित रिझॉल्व्हर फाइलमध्ये हाताने बदल करणे वाईट सवय आहे: फाइल पुन्हा लिहिली जाते आणि बदल नाहीसा होतो, किंवा बदल टिकतो आणि आता मार्ग नसलेल्या रिझॉल्व्हरला पिन करतो।
ही यादी एकदा, क्रमाने करा। कोणताही निकाल ठरवण्यापूर्वी प्रोफाइल कोणती रचना लागू करते ते ठरवा। दोन्ही फेऱ्यांमध्ये नाव, साधन आणि प्रत्यय स्थिर ठेवा। स्पष्ट क्वेरी अनुप्रयोग शोधापासून वेगळी ठेवा। फक्त उत्तर नाही, प्रभावी धोरण वाचा। तुलना लिहिल्यानंतर कॅशे शेवटी रिकाम्या करा। प्रत्यक्ष अनुप्रयोगाने पडताळा, नंतर एकदा रीबूट करा आणि डिस्कनेक्टची अवस्था अजूनही स्वच्छ आहे याची खात्री करा।