आपका CIFS माउंट VPN पर nsswitch के क्रम के कारण विफल होता है

टनल चालू है। फ़ाइल सर्वर पते से 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 को जल्दी-वापसी की क्रिया से पहले रखें, और इसे कॉन्फ़िगरेशन प्रबंधन से बदलें। हाथ से किया बदलाव अगली इमेज बिल्ड तक टिकता है, और फिर वही टिकट किसी दूसरी मशीन से आता है जिसे सुधार याद नहीं है।

रिज़ॉल्वर कोई खोज डोमेन नहीं है

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

प्रोफ़ाइल संपादित करने से पहले दोनों रूप जाँचें, क्योंकि दोनों विफलताएँ अलग दिशाओं में इशारा करती हैं। systemd-resolved वाले होस्ट पर टनल लिंक के अपने सर्वर और रूटिंग डोमेन होते हैं, इसलिए ग्लोबल फ़ाइल नहीं बल्कि लिंक पढ़ें।

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

अगर क्वेरी ऐसे लिंक को आरोपित है जो टनल नहीं ले जाता, तो DNS पता मौजूद होने पर भी रूटिंग डोमेन गायब है। यह resolved कॉन्फ़िगरेशन की नीति समस्या है, टनल की रूटिंग समस्या नहीं।

कंटेनर अपनी उत्तर की प्रति लेकर चलते हैं

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

इमेज को दोष देने से पहले कंटेनर के अंदर जाँचें। दो कमांड कुछ सेकंड में पूरा निदान दोहराती हैं, और दूसरी सिद्ध करती है कि किस रिज़ॉल्वर ने वास्तव में उत्तर दिया।

तभी शेयर और फ़िल्टर की ओर देखें

नाम हल होने के बाद बाकी विफलताएँ सामान्य नेटवर्क की होती हैं। 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 पोर्ट अस्वीकृत या समय-समाप्त होना दूसरी ओर फ़ायरवॉल या listener की समस्या है। अनसुलझा नाम रिज़ॉल्वर की समस्या है। और जो माउंट प्रमाणीकरण करता है पर अनुमति त्रुटियाँ लौटाता है वह दोनों में से कोई नहीं, इसलिए सत्र स्थापित होने के बाद नेटवर्क का सवाल फिर से न खोलें।

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