OpenVPN द्वारा DNS पुश करने के बाद स्थानीय Samba शेयर गायब हो गया

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

पाँच जाँचें, उस क्रम में जो हर चरण में सबसे अधिक संभावनाएँ हटाता है।

छोटे नाम का उत्तर कौन देता है

ऑपरेटिंग सिस्टम से पूछें, फ़ाइल मैनेजर से नहीं। resolvectl status हर लिंक से जुड़े DNS सर्वर दिखाता है और चिह्नित करता है कि कौन-सा लिंक डिफ़ॉल्ट रूट है, और छोटे नाम की क्वेरी उस सर्वर की सूचना देती है जिसने उत्तर दिया। इसे एक बार NAS नाम के लिए और एक बार ऐसे नाम के लिए चलाएँ जिसके बारे में आप जानते हैं कि वह ऑफ़िस डोमेन में मौजूद है। यदि दोनों उत्तर अलग-अलग सर्वरों से आते हैं, तो आपने विभाजन ढूँढ लिया है।

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

Samba गलत उत्तर पर क्यों विश्वास करता है

Samba नामों को name resolve order द्वारा तय एक निश्चित क्रम से हल करता है। अधिकांश वितरणों में डिफ़ॉल्ट में host होता है, यानी DNS, और यह NetBIOS प्रसारण जैसे केवल-LAN तंत्रों से पहले चलता है। इसलिए रिज़ॉल्वर पुश करने वाली टनल को हर शेयर नाम पर पहले इंकार का अधिकार मिलता है, जिसमें वे एक-लेबल नाम भी शामिल हैं जिन्हें कभी इमारत छोड़नी नहीं थी।

सामान्यतः अज्ञात नाम नकारात्मक उत्तर लौटाता है और अगले तंत्र को मौका मिलता है। कुछ रिज़ॉल्वर, विशेषकर उपभोक्ता ISP और सार्वजनिक रिज़ॉल्वर, अज्ञात नामों का उत्तर इसके बजाय खोज पृष्ठ या विज्ञापन पते से देते हैं। वह उत्तर रिज़ॉल्वर लाइब्रेरी को सफलता जैसा दिखता है, इसलिए Samba खोजना बंद कर देता है और ऐसे पते पर डायल करता है जिसका आपके नेटवर्क से कोई संबंध नहीं है।

परिणाम ऐसा शेयर है जो बिना त्रुटि संवाद के गायब हो जाता है। उस क्रम में कुछ भी VPN रूटिंग विफलता नहीं है, इसीलिए NAS को पिंग करना अभी भी काम करता है जबकि उस पर ब्राउज़ करना काम नहीं करता।

अलग-अलग दायरों वाली दो मरम्मतें

संकीर्ण मरम्मत पुश किए गए रिज़ॉल्वर को रखती है और बदलती है कि Samba उससे क्या पूछ सकता है। उस Samba कॉन्फ़िगरेशन में दो पंक्तियाँ जोड़ें जिसे डेमॉन वास्तव में पढ़ता है, फिर सेवा पुनः आरंभ करें:

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

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

विस्तृत मरम्मत कारण हटाती है: ऐसा रिज़ॉल्वर पुश करना बंद करें जो उन नामों का उत्तर देता है जो उसके नहीं हैं, या विभाजित-DNS नीति पुश करें ताकि केवल ऑफ़िस प्रत्यय ऑफ़िस रिज़ॉल्वर तक पहुँचें। प्रबंधित नेटवर्क में यह दीर्घकालिक रूप से बेहतर उत्तर है क्योंकि यह ब्राउज़र और पैकेज मैनेजर की भी रक्षा करता है, लेकिन इसके लिए सर्वर पक्ष पर प्रशासनिक पहुँच और ऐसा क्लाइंट चाहिए जो पुश की गई सेटिंग्स का पालन करे।

एक जानबूझकर चुनें। रिज़ॉल्वर परिवर्तन एक साथ हर एप्लिकेशन के नाम-समाधान को बदलता है, जो परिवर्तन रिकॉर्ड है, सपोर्ट कॉल के लिए संपादन नहीं।

प्रत्यय सब कुछ समझा सकता है

यदि क्लाइंट खोज प्रत्यय भी पुश करता है, तो छोटा स्थानीय नाम पूछे जाने से पहले ऑफ़िस डोमेन में फिर से लिखा जाता है। तब रिज़ॉल्वर बिल्कुल झूठ नहीं बोलता: उससे ऑफ़िस नाम के बारे में उचित प्रश्न पूछा गया और उसने सही उत्तर दिया। विज्ञापन-पते के मामले से इसे अलग करने के लिए रिज़ॉल्वर आउटपुट में पूछा गया नाम पढ़ें, क्योंकि फ़ाइल मैनेजर में दोनों खराबियाँ एक जैसी दिखती हैं।

यहाँ समाधान या तो पूरी तरह योग्य स्थानीय नाम का उपयोग करना है, या स्थानीय प्रत्यय का स्वामी विभाजित-DNS नियम जोड़ना है। दोनों में से किसी के लिए Samba को छूने की आवश्यकता नहीं।

फिर से कनेक्ट होने के बाद इसे सिद्ध करें

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

फिर टनल डिस्कनेक्ट और पुनः कनेक्ट करें और तीनों दोहराएँ। पुश किए गए विकल्प हर कनेक्शन पर फिर से लागू होते हैं, इसलिए केवल रनटाइम में मौजूद मरम्मत किसी कॉन्फ़िगरेशन फ़ाइल के बदले बिना गायब हो सकती है। हर प्रत्यय का स्वामी रिज़ॉल्वर और लागू लुकअप क्रम दर्ज करें, और तारीख भी लिखें, क्योंकि जब यह लौटेगा तो अगला क्लाइंट अपडेट स्पष्ट संदिग्ध है।

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