nsswitch क्रमका कारण तपाईंको CIFS माउन्ट VPN मा असफल हुन्छ

साझेदारी ठेगानाले जवाफ दिन्छ र नामले अड्किन्छ, त्यसैले SMB सुरु हुनुअघि नै खोजी मर्छ। getent लाई host सँग तुलना गर्नुहोस्, त्यसपछि hosts लाइन क्रममा पढ्नुहोस्।

टनेल सञ्चालनमा छ। फाइल सर्भरले ping लाई ठेगानाले जवाफ दिन्छ। त्यसपछि mount.cifs होस्टनामसहित केही समय त्यहीँ बस्छ र होस्ट पुग्न नसकिने रिपोर्ट गर्छ, र तपाईं कहिल्यै समस्या नभएको VPN प्रोफाइल पुनः बनाउन थाल्नुहुन्छ। Linux मा कुनै पनि SMB प्याकेट अस्तित्वमा आउनुअघि glibc ले नाम समाधान गर्छ, र त्यो रिजोल्भरको क्रमले DNS लाई सोध्नुअघि नै खोजी अन्त्य गर्न सक्छ। यो मैले हिँड्ने बाटो हो, क्लाइन्टबाट होइन, असफल भएको आदेशबाट सुरु हुन्छ।

असफलता सही ठाउँमा पढ्नुहोस्

दुई उपकरणले एउटै नाममा फरक बाटो लिन्छन्, र तिनको तुलना गर्न एक आदेश पुग्छ। getent कन्फिगर गरिएको नाम सेवा स्ट्याकबाट जान्छ; host र dig DNS लाई सिधै सोध्छन् र त्यो स्ट्याक बेवास्ता गर्छन्। यदि सिधा क्वेरीले ठेगाना फर्काउँछ र getent ले केही फर्काउँदैन भने, DNS सर्भर पुग्न सकिने छ र तपाईंको रिजोल्भर कन्फिगरेसन नै असफल हुँदैछ।

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

तेस्रो आदेश निर्णायक हो: यसले DNS स्रोतलाई बाध्य गर्छ र बाँकी स्ट्याक छोड्छ। त्यो चल्छ र साधारण getent चल्दैन भने, दोष क्रममा छ, टनेलमा होइन र सर्भरमा होइन भनी तपाईंले प्रमाणित गर्नुभयो।

hosts लाइन चाँडै रोकिने क्रम हो

glibc रिजोल्भरले /etc/nsswitch.conf पढ्छ र hosts: प्रविष्टि बायाँबाट दायाँ हिँड्छ। धेरै वितरणहरूले multicast खोजी पहिले आउने र त्यसमा चाँडो फर्कने कार्य जोडिएको लाइन दिन्छन्। त्यो कार्य सजावट होइन: mDNS ले “not found” भनी जवाफ दिँदा [NOTFOUND=return] ले सम्पूर्ण खोजी अन्त्य गर्छ, त्यसैले कर्पोरेट नाम VPN ले लादेको रिजोल्भरकहाँ कहिल्यै पठाइँदैन। कुनै कुराले त्यो लग गर्दैन, किनकि रिजोल्भरले अस्वीकार गर्न सक्ने क्वेरी नै पठाइएको थिएन। त्यसैले माउन्ट अड्किएजस्तो देखिन्छ र त्यसपछि होस्ट पुग्न नसकिने रिपोर्ट गर्छ।

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

mDNS मेट्नुको सट्टा DNS लाई चाँडो फर्कने कार्यअघि सार्नुहोस्, र यसलाई कन्फिगरेसन व्यवस्थापनबाट परिवर्तन गर्नुहोस्। हातले गरेको सुधार अर्को image निर्माणसम्म टिक्छ, अनि त्यही टिकट सुधार सम्झना नभएको अर्को मेसिनबाट आउँछ।

रिजोल्भर खोज डोमेन होइन

समाधानका लागि नाम प्रयास गरिनु पनि आवश्यक छ। fileserver जस्तो अपूर्ण नाम क्वेरी बोक्ने इन्टरफेसमा खोज डोमेन जोडिएपछि मात्र fileserver.corp.example बन्छ। खोज सूचीबिना DNS सर्भर लाद्ने VPN ले धेरै विशिष्ट विभाजन उत्पन्न गर्छ: पूर्ण योग्यता भएको नाम समाधान हुन्छ र हरेक छोटो नाम असफल हुन्छ.

प्रोफाइल सम्पादन गर्नुअघि दुवै रूप परीक्षण गर्नुहोस्, किनकि दुवै असफलता फरक दिशातिर देखाउँछन्। systemd-resolved होस्टमा टनेल लिङ्कका आफ्नै सर्भर र राउटिङ डोमेन हुन्छन्, त्यसैले ग्लोबल फाइल होइन, लिङ्क पढ्नुहोस्।

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

यदि क्वेरी टनेल नबोक्ने लिङ्कमा तोकियो भने DNS ठेगाना भए पनि राउटिङ डोमेन हराउँछ। त्यो resolved कन्फिगरेसनको नीति समस्या हो, टनेलको राउटिङ समस्या होइन।

कन्टेनरहरूले जवाफको आफ्नै प्रतिलिपि बोक्छन्

सामान्य image बाट बनेको कन्टेनर सामान्यतया स्थिर resolv.conf ल्याउँछ। होस्टमा गरिएका रिजोल्भर परिवर्तन त्यहाँ पुग्दैनन्, र खोज डोमेन पनि पुग्दैन, त्यसैले टनेलमार्फत साझेदारी माउन्ट गर्ने build काम असफल हुन्छ, तर त्यही आदेश कन्टेनरबाहिर चल्छ। कन्टेनरलाई आफ्नै DNS र खोजी सेटिङ compose फाइल वा run आर्गुमेन्टमा दिनुहोस्, होस्ट प्रोफाइलमा मात्र होइन।

image लाई दोष दिनुअघि कन्टेनरभित्र जाँच्नुहोस्। दुई आदेशले सम्पूर्ण निदान केही सेकेन्डमा पुनः उत्पादन गर्छन्, र दोस्रोले कुन रिजोल्भरले वास्तवमै जवाफ दियो भनी प्रमाणित गर्छ।

त्यसपछि मात्र साझेदारी र फिल्टर हेर्नुहोस्

नाम समाधान भएपछि, बाँकी असफलताहरू सामान्य सञ्जाल समस्या हुन्। SMB लाई सर्भरसम्म TCP 445 चाहिन्छ, र कार्यसमूह सूची ब्राउज गर्ने काम टनेलले अगाडि नपठाउन सक्ने नाम सेवाहरूमा निर्भर छ। सूची भरिने प्रतीक्षा गर्नुको सट्टा होस्टनामअनुसार म्याप गर्नुहोस्, र क्लाइन्टले कुन चरणमा पुग्यो भन्ने बताउन दिनुहोस्। अस्वीकृत जडान र शान्त timeout पनि छुट्याउन लायक छन्, किनकि पहिलोले सामान्यतया केही कुराले जवाफ दियो भन्ने र दोस्रोले केहीले पनि जवाफ दिएन भन्ने बुझाउँछ।

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

समाधान भएको ठेगानामा 445 पोर्ट अस्वीकृत वा समय सकिएको छ भने त्यो पारिको firewall वा listener समस्या हो। नसमाधान भएको नाम रिजोल्भर समस्या हो। र प्रमाणीकरण भएर अनुमति त्रुटि फर्काउने माउन्ट दुवै होइन, त्यसैले सत्र स्थापित भएपछि सञ्जाल प्रश्न पुनः नखोल्नुहोस्।

निष्कर्षलाई प्रमाणजत्तिकै साँघुरो राख्नुहोस्। ठेगाना चल्छ र नाम चल्दैन भने, टनेलले आफ्नो काम गरिरहेको छ, र सुधार रिजोल्भर क्रम, खोज डोमेन वा कन्टेनरको आफ्नै कन्फिगरेसनमा पर्छ।

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