VPN पर SMB अतिथि लॉगिन: Windows अभी भी पहचान मांगता है

ऑफ़िस VPN से जुड़ने पर फ़ाइल सर्वर पहुँच में आ जाता है और फिर भी शेयर पहुँच देने से इंकार करता है, जिससे यह निष्कर्ष निकलता है कि सुरंग टूटी हुई है। आमतौर पर ऐसा नहीं होता। SMB हर सत्र को अलग से प्रमाणित करता है, और Windows लगातार यह सख़्त कर रहा है कि वह अनाम लॉगिन के रूप में क्या स्वीकार करता है। नेटवर्क पथ और उपयोगकर्ता पहचान दो अलग आवश्यकताएँ हैं, और त्रुटि दूसरी से जुड़ी है।

सुरंग SMB पहचान का विकल्प क्यों नहीं बन सकती

सर्वर के साथ सबनेट साझा करने का अर्थ कभी उसकी फ़ाइलें पढ़ने की अनुमति नहीं था; यह केवल रूटिंग की समस्या हटाता है। Windows घटना 31017 तब दर्ज करता है जब उसका क्लाइंट असुरक्षित अतिथि लॉगिन को अवरुद्ध करता है, और यह निर्णय आपकी मशीन पर लिया जाता है, सर्वर पर नहीं। सुरंग SMB पैकेट निष्ठापूर्वक ले जाती है जबकि अतिथि सत्र अस्वीकार किया जाता है। इसलिए एक लैपटॉप समान घरेलू नेटवर्क पर काम करता है और दूसरा नहीं।

घटना को नेटवर्क खराबी नहीं, नीति का प्रमाण मानें। सुधार पहचान में या उपकरण में है।

क्लाइंट नीति और अस्वीकृति घटना पढ़ें

दो आउटपुट प्रश्न को जल्दी तय करते हैं: प्रभावी क्लाइंट कॉन्फ़िगरेशन और हाल की अस्वीकृति घटनाएँ।

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

झूठी अतिथि सेटिंग और हस्ताक्षर की आवश्यकता मिलकर किसी भी आगे की जाँच से पहले विफलता समझा देते हैं। घटना लॉग पुष्टि करता है कि क्लाइंट ने सत्र अस्वीकार किया, सर्वर ने क्रेडेंशियल नहीं। दूसरी मशीन पर सफल प्रयास में प्रयुक्त शेयर पथ और खाता लिख लें, क्योंकि कैश किया गया सत्र दो परीक्षणों को एक जैसा दिखा सकता है जबकि वे एक जैसे नहीं हैं। मौजूदा कनेक्शन net use से साफ़ करें, फिर तुलना करें, ताकि पुराना सत्र नए की ओर से उत्तर न दे।

नामित खाते का उपयोग करें और हस्ताक्षर बनाए रखें

टिकाऊ समाधान वह खाता है जिसे सर्वर जानता है, स्पष्ट रूप से दिया गया, जबकि हस्ताक्षर और एन्क्रिप्शन नीति अछूती रहती है। डायलॉग में कोई अनियमित नाम टाइप करने के बजाय कनेक्शन पर क्रेडेंशियल दें।

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

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

जब उपकरण केवल अतिथि जानता है

कुछ उपभोक्ता NAS बॉक्स बिना किसी खाता अवधारणा के शेयर देते हैं, जिससे दो ईमानदार विकल्प बचते हैं: उपकरण को अलग करें या बदल दें। इसे ऐसे खंड में रखें जहाँ किसी संवेदनशील वस्तु तक कोई रास्ता न हो, और सुविधा के अपवाद को पूरे क्लाइंट का डिफ़ॉल्ट बनने न दें। बैकअप या क्रेडेंशियल रखने वाला अतिथि शेयर Windows की परेशानी नहीं, बल्कि डेटा खुलने की समस्या है। अगर फ़र्मवेयर अपडेट उपयोगकर्ता खाते जोड़ता है, तो वही सस्ता दीर्घकालिक उत्तर है।

स्वीकृत खाता और नीति के मान टिकट में दर्ज करें। अन्यथा अगला व्यक्ति फिर सुरंग परीक्षण चलाएगा और उसी अस्वीकृति तक पहुँचेगा।