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 दिनुहोस् वा अनुप्रयोग बदल्नुहोस्; बीचको बाटो भनेको कहिल्यै खाली नहुने सहयोग लाइन हो।

कुन तह असफल भयो भन्न सक्दा यो यात्रा सकिन्छ: रिजोल्भर, प्रत्यय वा पुरानो खोज। जवाफ दिने रिजोल्भर र काम गर्ने नाम-रूप लेख्नुहोस्, किनकि अर्को व्यक्ति त्यही लक्षणबाट सुरु गर्नेछ।