SMB शेयर केवल VPN पर विफल होता है: साइनिंग या सबनेट टकराव?

LAN पर चलने वाला शेयर केवल टनल से विफल हो सकता है। साइनिंग अस्वीकृति, ओवरलैप होता सबनेट और पुराना SMB सत्र अलग करें।

ऑफ़िस में चलने वाली और घर पर टाइम आउट होने वाली मैप की गई ड्राइव अपने आप में लगभग कोई उपयोगी जानकारी नहीं देती। टनल स्पष्ट रूप से पैकेट ले जा रहा है, वरना सर्वर तक कुछ पहुँचता ही नहीं। जो विफल हुआ वह तीन परतों में से एक है: नाम गलत पते पर हल हुआ, क्लाइंट ने सत्र पर हस्ताक्षर करने से मना किया, या पुराना सत्र उस कनेक्शन से अधिक जीवित रहा जो उसे ढो रहा था। हर एक की मरम्मत अलग है, और तीन में से दो क्लाइंट की ओर हैं।

तीन खराबियाँ एक ही त्रुटि पहनती हैं

ड्राइव अक्षर नहीं बताता कि कौन सी परत टूटी, और त्रुटि पाठ आमतौर पर तीनों पर लागू होने लायक सामान्य होता है। उन्हें दो तेज़ सवालों से अलग करें: क्या सर्वर अपने IP पते पर जवाब देता है, और क्या पोर्ट 445 कनेक्शन स्वीकार करता है?

ये जवाब अनुमान के बजाय निर्णय तालिका बनाते हैं। अगर IP चलता है और नाम नहीं, तो यह नाम हल होने की ओर इशारा है। अगर दोनों चलते हैं और लॉगिन अस्वीकार होता है, तो यह साइनिंग की ओर इशारा है। अगर दोनों चलते हैं और टनल बाधा के बाद फ़ाइल पढ़ना अटक जाता है, तो यह पुराने सत्र की ओर इशारा है।

SymptomLayer to inspect
IP works, hostname times outDNS or subnet overlap
TCP 445 opens, logon refusedSMB signing policy
Hangs after reconnectSession state and timers

इन्हें उसी क्रम में निपटाएँ, क्योंकि गलत होस्ट पर हल होता नाम हर बाद के परीक्षण को अर्थहीन बना देता है।

शेयर को छूने से पहले नाम हल करें

अगर सर्वर अपने पते पर जवाब देता है और शेयर का नाम टाइम आउट हो जाता है, तो टनल अपना काम कर रहा है और क्लाइंट गलत जगह देख रहा है। दूरस्थ पहुँच में इसका अधिकांश हिस्सा दो कारण समझाते हैं।

पहला पतों का ओवरलैप है। जब ऑफ़िस 192.168.70.0/24 इस्तेमाल करता है और घर का राउटर वही रेंज बाँटता है, तो 192.168.70.20 पर हल होता होस्ट नाम टनल के पीछे के सर्वर की जगह स्थानीय डिवाइस की ओर इशारा कर सकता है। Windows तब अनुरोध स्थानीय रूप से भेज सकता है, रूट अस्वीकार कर सकता है, या ऐसे प्रिंटर पर हल कर सकता है जिसके पास संयोग से वह पता हो। मरम्मत एक तरफ को फिर से क्रमांकित करना है, न कि एक और रूट जोड़ना।

दूसरा DNS का दायरा है। बिना आंतरिक DNS सर्वर वाला VPN अडैप्टर, या ऐसा सर्वर जो टनल से पहुँच से बाहर हो, छोटे नामों को सार्वजनिक रिज़ॉल्वर तक जाने देता है। अडैप्टर की DNS प्रविष्टियाँ पढ़ें और शेयर को छूने से पहले आंतरिक नाम सीधे पूछें:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

अगर वह क्वेरी अपेक्षित पता लौटाती है, तो नाम हल होना तय है और समस्या स्टैक में ऊपर है।

दोनों सिरों पर साइनिंग आवश्यकता पढ़ें

पहुँच में आने वाला सर्वर जो हर लॉगिन अस्वीकार करता है, नेटवर्क खराबी नहीं बल्कि नीति बेमेल का संकेत है। Windows क्लाइंट पर SMB साइनिंग अनिवार्य कर सकता है, और बिना हस्ताक्षर करने वाला सर्वर या NAS सत्र पूरा नहीं कर सकता, चाहे टनल कितना भी स्वस्थ हो।

आप नीति संपादक में खोजे बिना क्लाइंट सेटिंग पढ़ सकते हैं:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

सर्वर पक्ष का संगत मान सर्वर के SMB कॉन्फ़िगरेशन में है, और दोनों को सहमत होना चाहिए। एक रिपोर्ट किए गए मामले में क्लाइंट पर आवश्यकता स्थानीय नीति से सक्षम थी जबकि सर्वर बिल्कुल हस्ताक्षर नहीं कर रहा था; उसे अक्षम करने और gpupdate /force चलाने से शेयर तुरंत बहाल हो गया। यह कारण की पुष्टि के लिए नैदानिक कदम है, स्थायी समाधान नहीं।

जहाँ सर्वर समर्थन करता है वहाँ दोनों सिरों पर साइनिंग चालू करना पसंद करें। किसी शेयर के काम करने के लिए सुरक्षा सेटिंग बदलने को उसके पिछले मान और कारण के साथ दर्ज करना चाहिए, ताकि अगले ऑडिट में किसी को उसे फिर से खोजना न पड़े।

टाइमर ट्यून करने से पहले पुराना सत्र साफ़ करें

जो शेयर केवल VPN गिरने और फिर जुड़ने के बाद अटकता है, वह आमतौर पर ऐसा सत्र पकड़े रहता है जिसे सर्वर पहले ही छोड़ चुका है। सर्वर निष्क्रिय SMB सत्रों को LanmanServer\Parameters के अंतर्गत Autodisconnect टाइमर पर बंद करता है, जो डिफ़ॉल्ट रूप से 15 मिनट है, जबकि क्लाइंट का अपना SessTimeout LanmanWorkstation\Parameters के अंतर्गत है। इन मानों से लंबा व्यवधान हर सिरे को सत्र के बारे में अलग धारणा के साथ छोड़ देता है।

इसे तय क्रम में दोहराएँ ताकि परिणाम का कोई अर्थ हो: टनल जोड़ें, शेयर खोलें, टनल दो मिनट के लिए काटें, उसे बहाल करें, फिर फ़ाइल पढ़ने का प्रयास करें। अगर माउंट अपने आप ठीक हो जाए तो टाइमर छोड़ दें। अगर यह दोबारा माउंट होने तक अटका रहे, तो टनल खड़े होने के बाद शेयर दोबारा जोड़ें, उसके अस्तित्व से पहले माउंट करने के बजाय, और देखें कि माउंट सहायक फिर से प्रयास करता है या नहीं।

टाइम आउट बढ़ाना अस्थिर लिंक के लिए उचित अंतिम कदम है, लेकिन यह लक्षण का इलाज करता है। ऐसा क्लाइंट जो सर्वर के भूल चुके सत्र का अधिक देर तक इंतज़ार करता है, फिर भी इंतज़ार करता है।

माउंट के ज़रिए एक फ़ाइल पढ़कर और फिर एक बार और टनल काटकर बहाल करके समाप्त करें। वह स्वीकृति परीक्षण तीनों परतों को एक साथ कवर करता है, और यह एकमात्र परीक्षण है जो उपयोगकर्ता के वास्तविक काम से मेल खाता है।

संबंधित लेख