साइट VPN मार्फत म्याप गरिएको ड्राइभ: DNS, SMB र UNC पथ
नेटवर्क खोज राउटेड लिंक पार गर्दैन, तर नाम भएको UNC पथ पार गर्छ। DNS सर्भरतिर देखाउनुहोस्, SMB दुवै दिशामा खोल्नुहोस् र त्यसपछि ड्राइभ म्याप गर्नुहोस्।
Explorer मा नेटवर्क पृष्ठले स्थानीय खण्डमा आफ्नो घोषणा गरेका यन्त्रहरू देखाउँछ, र राउटेड टनेलले ती घोषणाहरूमध्ये एउटा पनि बोक्दैन। त्यसैले सर्भर पूर्ण रूपमा पहुँचयोग्य हुन सक्छ जबकि प्रयोगकर्ताको अगाडिको विन्डो खाली रहन्छ। नाम भएको UNC पथ खोजमा पटक्कै निर्भर छैन, र समाधान भनेको नाम समाधान होस् र पोर्टले जवाफ देओस्। खाली विन्डो गलत तहको लक्षण हो, बिग्रिएको साझाको होइन।
खोज र पहुँच एउटै कुरा होइन
Windows नजिकका मेसिनहरू ब्रोडकास्ट डोमेनका लागि बनाइएका प्रोटोकलद्वारा खोज्छ र त्यसपछि भेटिएको कुरा सुविधाको सूचीका रूपमा देखाउँछ। त्यो सूचीमा केही पनि SMB फाइल पहुँचका लागि आवश्यक छैन। सर्भरको नाम थाहा भएको र TCP 445 सम्म पुग्न सक्ने क्लाइन्टले साझा खोल्छ, मेसिन कहिल्यै नेटवर्कमा देखिए पनि नदेखिए पनि।
दुई तहहरू स्वतन्त्र रूपमा असफल हुन्छन्, त्यसैले "मलाई यो देखिँदैन" र "मैले यो खोल्न सक्दिन" फरक जाँचको योग्य छन्। सूची हेर्नुले खोजको बारेमा बताउँछ; पथ खोल्नुले सेवाको बारेमा बताउँछ।
साझा म्याप गर्नुअघि सर्भरलाई नाम दिनुहोस्
फाइल सर्भर DNS मा उसको अर्को छेउको ठेगानासँग प्रकाशित गर्नुहोस् र क्लाइन्ट साइटलाई त्यो जोनका लागि जवाफ दिन सक्ने resolver तिर देखाउनुहोस्। पूर्ण रूपमा योग्य नामले स्थानीय प्रत्यय खोज सूचीमा निर्भरता टार्छ, जुन सामान्यतया छोटो नाम एउटा साइटमा चल्ने र अर्कोमा असफल हुने कारण हो।
वातावरणले Active Directory प्रयोग गर्छ भने, नाम समाधान प्रमाणीकरणको पनि भाग हो: क्लाइन्टले Kerberos का लागि डोमेन नियन्त्रकसम्म पुग्नुपर्छ, र धेरै बेमेल घडीले टिकट आदानप्रदान असफल बनाउँछ। यो SMB पहुँचभन्दा फरक समस्या हो र प्रमाणहरूको त्रुटिजस्तो देखिन्छ। पासवर्ड फेरि लेख्नुअघि डोमेन नियन्त्रक जाँच्नुहोस्।
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
दुवै दिशामा राउटिङ र फिल्टरिङ
साइट-देखि-साइट टनेललाई स्थानीय राउट तालिकामा टाढाको प्रिफिक्स र टाढाको तालिकामा स्थानीय प्रिफिक्स चाहिन्छ, र हरेक छेउको फायरवालले आउँदो ट्राफिकलाई अनुमति दिनुपर्छ। एकतर्फी कन्फिगरेसनले खुल्ने र कहिल्यै जवाफ नदिने जडान बनाउँछ, जसलाई प्रयोगकर्ताले साझा ढिलो भएको भन्छन्। पहिले टनेलका आफ्नै काउन्टर जाँच्नुहोस्। प्याकेट बाहिर जान्छन् र केही फर्कंदैन भने फर्कने मार्ग वा टाढाको फिल्टर हेर्नुहोस्।
WireGuard मा पीयरका अनुमति प्राप्त IP र अपरेटिङ सिस्टमका रुटहरू त्यो डिजाइनसँग मिल्नुपर्छ। टनेलले प्याकेट बोक्छ; यसले DNS रेकर्ड वा साझा अनुमति प्रदान गर्दैन कुनै पनि छेउमा।
फायरवाल नियम वास्तविक स्रोत नेटवर्कमा आधारित राख्नुहोस् जुन जोडिनेछ, र अपवाद लेख्नुहोस्। डिजाइनले बाटोमा कतै ठेगाना अनुवाद गर्छ भने नियमले अनुवादित स्रोत प्रयोग गर्नुपर्छ, र मूल क्लाइन्ट ठेगाना अब लगमा देखिँदैन।
प्रमाणीकरण गर्नुहोस्, त्यसपछि ड्राइभ म्याप गर्नुहोस्
Explorer विन्डोको सट्टा आदेशहरूद्वारा तहहरू पार गर्नुहोस्:
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:noदोस्रो आदेशले TCP पथ प्रमाणित गर्छ, केही पढ्ने अधिकार होइन। तेस्रो त्यो ठाउँ हो जहाँ प्रमाणीकरण र अधिकार लागू हुन्छ, र त्यहाँको असफलताले तपाईंलाई राउटरतिर होइन, साझा र फाइल प्रणालीका अनुमतितिर पठाउनुपर्छ।
SMB हस्ताक्षर र विद्यमान प्रमाणीकरण नीति अक्षुण्ण राख्नुहोस्। स्पष्ट पथका लागि SMB1 फेरि सक्रिय गर्न वा खोज ब्रोडकास्ट टनेलबाट पठाउन आवश्यक छैन, र TCP 445 निजी पथमा रहनुपर्छ, इन्टरनेटतिर फर्किएको फर्वार्डमा होइन। प्रयोगकर्तालाई स्वीकृत नाममा व्यवस्थित सर्टकट वा म्याप गरिएको ड्राइभ दिनुहोस्, र खाली नेटवर्क पृष्ठले अर्थ राख्दैन।