OpenVPN ने DNS पुश केल्यानंतर स्थानिक Samba शेअर गायब झाला

Samba स्थानिक शेअर त्या क्षणी गमावतो जेव्हा OpenVPN कनेक्ट होतो, आणि टनेल जवळपास कधीच कारण नसतो। माउंट ठीक आहे, NAS सुरू आहे, आणि टनेलने स्थापित केलेला रिझोल्व्हर अशा नावाबद्दल प्रश्नांना उत्तर देत आहे जे त्याने कधीच पाहिले नाही। Samba आपल्या लुकअप क्रमात लवकर त्या रिझोल्व्हरला विचारतो, उत्तरावर विश्वास ठेवतो आणि जिथे काहीही ऐकत नाही अशा पत्त्यावर कनेक्ट होतो। शेअर दुरुस्त करणे म्हणजे माउंट नाही, उत्तर दुरुस्त करणे।

पाच तपासण्या, त्या क्रमाने जो प्रत्येक पायरीत सर्वाधिक शक्यता वगळतो।

लहान नावाला कोण उत्तर देतो

फाइल मॅनेजरला नाही, ऑपरेटिंग सिस्टमला विचारा। resolvectl status प्रत्येक लिंकला जोडलेले DNS सर्व्हर छापतो आणि कोणती लिंक डीफॉल्ट मार्ग आहे हे चिन्हांकित करतो, आणि लहान नावाची क्वेरी उत्तर देणाऱ्या सर्व्हरची माहिती देते। NAS नावासाठी एकदा आणि ऑफिस डोमेनमध्ये आहे हे तुम्हाला माहीत असलेल्या नावासाठी आणखी एकदा ते चालवा। दोन्ही उत्तरे वेगळ्या सर्व्हरवरून आल्यास, तुम्ही विभाजन शोधले आहे।

उत्तर नकारात्मक उत्तर होते की पत्ता होता ते तपासा। नकारात्मक उत्तर म्हणजे Samba ने दुसऱ्या यंत्रणेकडे जायला हवे होते, आणि बिघाड दुसरीकडे आहे। पत्ता म्हणजे Samba खऱ्या ठिकाणी कनेक्ट झाले आणि काहीही परत मिळाले नाही।

Samba चुकीच्या उत्तरावर का विश्वास ठेवतो

Samba name resolve order ने ठरवलेल्या निश्चित क्रमाने नावे सोडवतो। बहुतेक वितरणांमध्ये डीफॉल्टमध्ये host असतो, म्हणजे DNS, आणि तो NetBIOS प्रसारणासारख्या फक्त-लॅन यंत्रणांपूर्वी चालतो। त्यामुळे रिझोल्व्हर पुश करणाऱ्या टनेलला प्रत्येक शेअर नावावर पहिल्या नकाराचा हक्क मिळतो, इमारत कधीच सोडू नये अशा एक-लेबल नावांसह।

सामान्यतः अज्ञात नाव नकारात्मक उत्तर परत करते आणि पुढील यंत्रणेला संधी मिळते। काही रिझोल्व्हर, विशेषतः ग्राहक ISP आणि सार्वजनिक, अज्ञात नावांना त्याऐवजी शोध पृष्ठ किंवा जाहिरात पत्त्याने उत्तर देतात। ते उत्तर रिझोल्व्हर लायब्ररीला यशासारखे वाटते, म्हणून Samba शोधणे थांबवतो आणि तुमच्या नेटवर्कशी काहीही संबंध नसलेल्या पत्त्यावर डायल करतो।

परिणाम म्हणजे त्रुटी संवादाशिवाय गायब होणारा शेअर। त्या क्रमात काहीही VPN राउटिंग बिघाड नाही, म्हणून NAS ला ping अजूनही चालतो पण त्यावर ब्राउझ करणे चालत नाही।

वेगवेगळ्या व्याप्तीच्या दोन दुरुस्त्या

अरुंद दुरुस्ती पुश केलेला रिझोल्व्हर ठेवते आणि Samba त्याला काय विचारू शकतो ते बदलते। डेमन प्रत्यक्षात वाचतो त्या Samba कॉन्फिगरेशनमध्ये दोन ओळी जोडा, नंतर सेवा पुन्हा सुरू करा:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

त्या यादीत host नसल्यास शेअर लुकअपच्या मार्गातून DNS बाहेर पडतो, आणि एक-लेबल नावे स्थानिक विभागात राहतात। ऑफिस नावे इतर प्रत्येक प्रोग्रामसाठी अजूनही सामान्यपणे सोडवली जातात, कारण हे फक्त Samba बदलते। किंमत ही आहे की Samba आता DNS अजिबात वापरू शकत नाही, त्यामुळे पूर्णपणे पात्र ऑफिस नावाने पत्ता दिलेला शेअर समस्या बनतो।

विस्तृत दुरुस्ती कारण काढून टाकते: स्वतःची नसलेली नावे उत्तर देणारा रिझोल्व्हर पुश करणे थांबवा, किंवा विभाजित-DNS धोरण पुश करा जेणेकरून फक्त ऑफिस प्रत्यय ऑफिस रिझोल्व्हरपर्यंत पोहोचतील। व्यवस्थापित नेटवर्कमध्ये हे दीर्घकालीन चांगले उत्तर आहे कारण ते ब्राउझर आणि पॅकेज मॅनेजरचेही संरक्षण करते, पण त्यासाठी सर्व्हर बाजूला प्रशासकीय प्रवेश आणि पुश केलेल्या सेटिंग्जचे पालन करणारा क्लायंट आवश्यक आहे।

एक जाणीवपूर्वक निवडा। रिझोल्व्हर बदल एकाच वेळी प्रत्येक अनुप्रयोगासाठी नाव-निराकरण बदलतो, जो बदल नोंद आहे, सपोर्ट कॉलसाठी संपादन नाही।

प्रत्यय सर्व काही स्पष्ट करू शकतो

क्लायंट शोध प्रत्ययही पुश करत असेल, तर लहान स्थानिक नाव विचारण्यापूर्वी ऑफिस डोमेनमध्ये पुन्हा लिहिले जाते। तेव्हा रिझोल्व्हर अजिबात खोटे बोलत नाही: त्याला ऑफिस नावाबद्दल न्याय्य प्रश्न विचारला गेला आणि त्याने बरोबर उत्तर दिले। जाहिरात-पत्त्याच्या प्रकरणापासून हे वेगळे करण्यासाठी रिझोल्व्हर आउटपुटमधील विचारलेले नाव वाचा, कारण फाइल मॅनेजरमध्ये दोन्ही बिघाड एकसारखे दिसतात।

इथे उपाय म्हणजे पूर्णपणे पात्र स्थानिक नाव वापरणे किंवा स्थानिक प्रत्ययाचा मालक असलेला विभाजित-DNS नियम जोडणे। दोन्हीपैकी कशालाही Samba ला स्पर्श करण्याची गरज नाही।

पुन्हा कनेक्ट झाल्यानंतर ते सिद्ध करा

एका सत्रात तीन नावे तपासा: लहान नावाने स्थानिक शेअर, नावाने ऑफिस होस्ट, आणि एक सामान्य वेबसाइट। पहिले चालले आणि दुसरे तुटले, तर दुरुस्तीने बिघाड काढून टाकण्याऐवजी हलवला। तिसरे तुटले, तर रिझोल्व्हर बदल अपेक्षेपेक्षा पुढे गेला आणि आता प्रत्येक लुकअप संशयास्पद आहे।

नंतर टनेल डिस्कनेक्ट करा आणि पुन्हा कनेक्ट करा आणि तिन्ही पुन्हा करा। पुश केलेले पर्याय प्रत्येक कनेक्शनवर पुन्हा लागू होतात, त्यामुळे फक्त रनटाइममध्ये असलेली दुरुस्ती कॉन्फिगरेशन फाइल न बदलता गायब होऊ शकते। प्रत्येक प्रत्ययाचा मालक रिझोल्व्हर आणि लागू लुकअप क्रम नोंदवा, आणि तारीखही लिहा, कारण हे परत आल्यावर पुढील क्लायंट अपडेट हाच स्पष्ट संशयित आहे।

पाचही तपासण्यांनंतरही शेअर अयशस्वी झाल्यास, दुसरे काहीही बदलण्यापूर्वी अचूक क्वेरी आणि अचूक उत्तर कॅप्चर करा। त्या दोन ओळी रिझोल्व्हर बिघाडाची खऱ्या अर्थाने नसलेल्या नावापासून वेगळी करतात, आणि तुम्ही लिहू शकता अशी सर्वात वेगवान हस्तांतरण टीप आहे।