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 छुनु पर्दैन।

पुनः जडानपछि यो प्रमाणित गर्नुहोस्

एक सत्रमा तीन नाम जाँच्नुहोस्: छोटो नामले स्थानीय सेयर, नामले अफिस होस्ट, र एउटा साधारण वेबसाइट। पहिलो चल्यो र दोस्रो भाँचियो भने, मर्मतले त्रुटि हटाउनुको सट्टा सार्यो। तेस्रो भाँचियो भने, रिजोल्भर परिवर्तन इच्छाभन्दा पर गयो र अब हरेक लुकअप शंकास्पद छ।

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

पाँचै जाँचपछि पनि सेयर असफल भयो भने, अरू केही बदल्नु अघि सही क्वेरी र सही जवाफ कैद गर्नुहोस्। ती दुई लाइनले रिजोल्भर त्रुटिलाई साँच्चै नभएको नामबाट छुट्याउँछन्, र यो तपाईंले लेख्न सक्ने सबैभन्दा छिटो हस्तान्तरण टिप्पणी हो।

सम्बन्धित लेखहरू