VPN होस्टनावे अयशस्वी होतात, IP पत्ते काम करतात: कुठे पाहावे

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

नाव असा प्रश्न विचारते जो पत्ता विचारत नाही

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

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

बोगद्याने प्रत्यक्षात बसवलेला रिझोल्व्हर वाचा

ऑपरेटिंग सिस्टमला विचारा अंतर्गत झोनच्या क्वेरी कोणता रिझोल्व्हर हाताळतो, VPN क्लायंटचा इंटरफेस कोणत्याची जाहिरात करतो ते नव्हे। अंतर्गत झोनशिवाय सार्वजनिक रिझोल्व्हर लादणारा सर्व्हर नेमकी हीच अयशस्वीता निर्माण करतो, आणि ही मार्गदर्शन बिघाड नव्हे तर संरचना चूक आहे।

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

अंतर्गत झोन योग्य सर्व्हरमार्फत सुटत असेल तर थांबा। रिझोल्व्हर तुमची समस्या नाही।

प्रत्यय अयशस्वी लहान नावे स्पष्ट करतात

एका लेबलचे नाव क्वेरी पाठवण्यापूर्वी जोडणीच्या प्रत्यय यादीने विस्तारले जाते। VPN अंतर्गत प्रत्यय देत नसेल, तर fileserver कधीही fileserver.corp.example होत नाही, आणि क्वेरी कोणत्याही सार्वजनिक रिझोल्व्हरला न माहीत असलेले नाव म्हणून बाहेर पडते। प्रत्यय लादणे किंवा पूर्ण नाव टाइप करणे सर्व्हरवर काहीही न बदलता गृहीतक तपासते।

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

प्रत्यय जोडल्याने हे सुटल्यास, उरलेले काम म्हणजे प्रत्येक वापरकर्त्याला तो टाइप करायला सांगण्याऐवजी तो प्रत्यय VPN प्रोफाइलमार्फत पोहोचवणे।

NetBIOS आणि WINS वेगळी यंत्रणा आहेत

जुना SMB अजूनही नुसते नाव NetBIOS नाव सेवेने शोधू शकतो, जी प्रसारणाने किंवा WINS सर्व्हरमार्फत उत्तर देते। प्रसारण एका प्रसारण डोमेनमध्ये राहते आणि पहिल्या राउटरवर थांबते, म्हणून ते बोगद्याच्या पलीकडे जाऊ शकत नाही; WINS चालते कारण क्लायंटकडे नोंदणी आणि विचारण्यासाठी एक युनिकास्ट पत्ता असतो। म्हणूनच केवळ IP वाहणारा VPN देखील WINS संरचित आणि पोहोचण्यायोग्य असताना जुनी नावे टिकवू शकतो।

nbtstat -n
nbtstat -R

आधुनिक SMB साठी DNS आणि पूर्ण नावावर विसंबा, आणि जुना मार्ग निवृत्त करा। तो खरोखर जुना असेल तर WINS द्या किंवा अनुप्रयोग बदला; मधला मार्ग म्हणजे कधीही रिकामी न होणारी मदत रांग।

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