VPN होस्टनाम विफल होते हैं, IP पते काम करते हैं: कहाँ देखें

आप साझा संसाधन को पते से खोल सकते हैं और वही साझा संसाधन नाम से विफल हो जाता है, जिसका अर्थ है कि सुरंग पैकेट ले जा रही है और नाम की परत नहीं। यह एक अवलोकन फ़ायरवॉल और रूट के बदलावों से होने वाले चक्कर से बचा लेता है। नामों को एक प्रत्यय, एक रिज़ॉल्वर और क्वेरी के लिए एक मार्ग चाहिए, और VPN क्लाइंट इनमें से कोई भी स्थापित किए बिना रूट स्थापित कर सकता है। नीचे दी गई चार जाँचें क्रम से करें और पहली टूटने वाली पर रुक जाएँ।

नाम वह प्रश्न पूछता है जो पता नहीं पूछता

पता एक गंतव्य है जिसका उपयोग स्टैक तुरंत कर सकता है। छोटा नाम एक प्रश्न है जिसे प्रत्यय से बढ़ाना, रिज़ॉल्वर को भेजना और किसी ऐसी चीज़ द्वारा उत्तर दिलाना पड़ता है जो ज़ोन जानती हो। जो सुरंग रूट स्थापित करती है पर रिज़ॉल्वर नहीं, वह पहले को काम करता और दूसरे को टूटा हुआ छोड़ देती है। इसी कारण बहुत भिन्न VPN उत्पादों में लक्षण इतना एक-सा दिखता है।

पते से बाहर की ओर काम करें: पहले पूरा नाम, फिर नंगा होस्टनाम, और लिख लें कि तीनों में से कौन काम करता है। यह पैटर्न बताता है कि एक भी कॉन्फ़िगरेशन स्क्रीन खोलने से पहले कौन-सी परत देखनी है। जब पूरा नाम हल हो रहा हो तो रूटों का अनुमान लगाना व्यर्थ श्रम है।

वह रिज़ॉल्वर पढ़ें जो सुरंग ने वास्तव में स्थापित किया

ऑपरेटिंग सिस्टम से पूछें आंतरिक ज़ोन की क्वेरी कौन-सा रिज़ॉल्वर संभालता है, यह नहीं कि 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 सर्वर को एक लिंक और रूटिंग डोमेन के समूह से बाँधती है, इसलिए थोपा गया सर्वर जो सुरंग के लिंक से जुड़ा नहीं है, वैसे व्यवहार करता है जैसे वह वहाँ ही न हो। स्टब फ़ाइल नहीं, लिंक के अनुसार स्थिति देखें, जो शायद केवल स्थानीय रिज़ॉल्वर की ओर इशारा करती हो। वही विभाजन दूसरी दिशा में भी दिखता है: मौजूद पर सुरंग इंटरफ़ेस पर लागू न किया गया खोज डोमेन ऐसी छोटे-नाम विफलताएँ पैदा करता है जो यादृच्छिक लगती हैं।

अगर प्रत्यय जोड़ने से यह ठीक हो जाए, तो बचा हुआ काम यह है कि हर उपयोगकर्ता से उसे टाइप करने को कहने के बजाय वह प्रत्यय VPN प्रोफ़ाइल के माध्यम से पहुँचाया जाए।

NetBIOS और WINS एक भिन्न तंत्र हैं

पुराना SMB अब भी NetBIOS नाम सेवा से नंगा नाम खोज सकता है, जो ब्रॉडकास्ट पर या WINS सर्वर के माध्यम से उत्तर देती है। ब्रॉडकास्ट एक ब्रॉडकास्ट डोमेन के भीतर रहता है और पहले राउटर पर रुक जाता है, इसलिए सुरंग के पार नहीं जा सकता; WINS काम करता है क्योंकि क्लाइंट के पास पंजीकरण करने और पूछने के लिए एक यूनिकास्ट पता है। इसीलिए केवल IP ले जाने वाला VPN भी पुराने नाम तब सहारा दे सकता है जब WINS कॉन्फ़िगर और पहुँच-योग्य हो।

nbtstat -n
nbtstat -R

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

यह यात्रा तब समाप्त होती है जब आप कह सकें कि कौन-सी परत विफल हुई: रिज़ॉल्वर, प्रत्यय या पुरानी खोज। जिस रिज़ॉल्वर ने उत्तर दिया और जो नाम-रूप काम कर गया उसे लिख लें, क्योंकि अगला व्यक्ति उसी लक्षण से शुरू करेगा।