SMB शेअर फक्त VPN वर अयशस्वी होतो: साइनिंग की सबनेट टक्कर?
LAN वर चालणारा शेअर फक्त टनेलमधून अयशस्वी होऊ शकतो. साइनिंग नाकारणे, ओव्हरलॅप होणारे सबनेट आणि जुने SMB सत्र वेगळे करा.
ऑफिसमध्ये चालणारी आणि घरी टाइमआउट होणारी मॅप केलेली ड्राइव्ह स्वतःहून जवळपास कोणतीही उपयुक्त माहिती देत नाही. टनेल स्पष्टपणे पॅकेट वाहत आहे, नाहीतर सर्व्हरपर्यंत काहीच पोहोचले नसते. जे अयशस्वी झाले ते तीन स्तरांपैकी एक आहे: नाव चुकीच्या पत्त्यावर सोडवले गेले, क्लायंटने सत्रावर स्वाक्षरी करण्यास नकार दिला, किंवा जुने सत्र ते वाहणाऱ्या कनेक्शनपेक्षा जास्त जगले. प्रत्येकाची दुरुस्ती वेगळी आहे, आणि तीनपैकी दोन क्लायंटच्या बाजूला आहेत.
तीन बिघाड एकच त्रुटी परिधान करतात
ड्राइव्ह अक्षर कोणता स्तर तुटला हे सांगत नाही, आणि त्रुटीचा मजकूर सहसा तिन्हींना लागू होण्याइतका सामान्य असतो. त्यांना दोन झटपट प्रश्नांनी वेगळे करा: सर्व्हर त्याच्या IP पत्त्यावर उत्तर देतो का, आणि पोर्ट 445 कनेक्शन स्वीकारतो का?
ही उत्तरे अंदाजाऐवजी निर्णय तक्ता तयार करतात. IP चालतो आणि नाव नाही, तर ते नाव सोडवण्याकडे निर्देश करते. दोन्ही चालतात आणि लॉगिन नाकारले जाते, तर ते साइनिंगकडे निर्देश करते. दोन्ही चालतात आणि टनेल खंडानंतर फाइल वाचन अडकते, तर ते जुन्या सत्राकडे निर्देश करते.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session 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 अंतर्गत आहे. या मूल्यांपेक्षा लांब खंड प्रत्येक टोकाला सत्राबद्दल वेगळी कल्पना ठेवतो.
निकालाला अर्थ मिळावा म्हणून ते ठरलेल्या क्रमाने पुन्हा तयार करा: टनेल जोडा, शेअर उघडा, टनेल दोन मिनिटांसाठी तोडा, तो पुन्हा सुरू करा, आणि मग फाइल वाचण्याचा प्रयत्न करा. माउंट स्वतःहून सावरले तर टाइमरला हात लावू नका. तो पुन्हा माउंट होईपर्यंत अडकत असेल, तर टनेल उभा राहिल्यानंतर शेअर पुन्हा जोडा, तो अस्तित्वात येण्यापूर्वी माउंट करण्याऐवजी, आणि माउंट सहाय्यक पुन्हा प्रयत्न करतो का ते तपासा.
टाइमआउट वाढवणे अस्थिर लिंकसाठी योग्य शेवटचे पाऊल आहे, पण ते लक्षणावर उपचार करते. सर्व्हरने विसरलेल्या सत्राची जास्त वेळ वाट पाहणारा क्लायंट तरीही वाट पाहत असतो.
माउंटद्वारे एक फाइल वाचून आणि मग अजून एकदा टनेल तोडून पुन्हा सुरू करून समारोप करा. ती स्वीकृती चाचणी तीनही स्तर एकाच वेळी व्यापते, आणि वापरकर्ता प्रत्यक्षात काय करतो याशी जुळणारी ती एकमेव चाचणी आहे.