साइट 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 निजी मार्गावर राहिला पाहिजे, इंटरनेटकडे वळलेल्या फॉरवर्डवर नाही. वापरकर्त्यांना मंजूर नावावर व्यवस्थापित शॉर्टकट किंवा मॅप केलेला ड्राइव्ह द्या, आणि रिकामे नेटवर्क पृष्ठ महत्त्वाचे राहणार नाही.