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 अन्तर्गत छ। ती मानभन्दा लामो अवरोधले हरेक छेउलाई सत्रबारे फरक धारणा छोड्छ।
नतिजाले केही अर्थ राखोस् भनेर यसलाई निश्चित क्रममा दोहोर्याउनुहोस्: टनेल जोड्नुहोस्, साझेदारी खोल्नुहोस्, टनेल दुई मिनेटका लागि काट्नुहोस्, पुनर्स्थापित गर्नुहोस्, त्यसपछि फाइल पढ्न प्रयास गर्नुहोस्। यदि माउन्ट आफैं सुधारिन्छ भने टाइमरलाई छोड्नुहोस्। यदि पुनः माउन्ट नगरेसम्म अड्किन्छ भने, टनेल उभिएपछि साझेदारी फेरि जोड्नुहोस्, यो अस्तित्वमा आउनुअघि माउन्ट गर्नुको सट्टा, र माउन्ट सहायकले फेरि प्रयास गर्छ कि जाँच्नुहोस्।
टाइमआउट बढाउनु अस्थिर लिङ्कका लागि उचित अन्तिम कदम हो, तर यसले लक्षणको उपचार गर्छ। सर्भरले बिर्सेको सत्रको लामो प्रतीक्षा गर्ने क्लाइन्टले अझै प्रतीक्षा गर्छ।
माउन्टमार्फत एउटा फाइल पढेर र फेरि एकपटक टनेल काटेर पुनर्स्थापित गरेर टुंग्याउनुहोस्। त्यो स्वीकृति परीक्षणले तीनवटै तह एकैचोटि समेट्छ, र प्रयोगकर्ताले वास्तवमै गर्ने कामसँग मेल खाने यो मात्र परीक्षण हो।