VPN-এ আপনার CIFS মাউন্ট ব্যর্থ হয় nsswitch-এর ক্রমের কারণে

শেয়ারটি ঠিকানায় সাড়া দেয় আর নামে আটকে যায়, তাই 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-কে আগাম-প্রত্যাবর্তন ক্রিয়ার আগে সরান, আর এটি কনফিগারেশন ম্যানেজমেন্টের মাধ্যমে বদলান। হাতে করা সম্পাদনা পরের ইমেজ বিল্ড পর্যন্ত টেকে, তারপর একই টিকিট অন্য একটি মেশিন থেকে আসে যার এই সমাধানের কোনো স্মৃতি নেই।

রিজলভার কোনো সার্চ ডোমেইন নয়

সমাধানের জন্য নামটিও চেষ্টা করা দরকার। 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 পোর্ট প্রত্যাখ্যাত বা timeout হলে সেটি ওপাশে ফায়ারওয়াল বা listener-এর সমস্যা। অসমাধান হওয়া নাম হলো রিজলভারের সমস্যা। আর যে মাউন্ট প্রমাণীকরণ করে কিন্তু অনুমতি ত্রুটি ফেরত দেয়, সেটি দুটোর কোনোটিই নয়, তাই সেশন প্রতিষ্ঠিত হওয়ার পর নেটওয়ার্ক প্রশ্নটি আবার খুলবেন না।

সিদ্ধান্তটিকে প্রমাণের মতো সংকীর্ণ রাখুন। যখন ঠিকানা কাজ করে আর নাম করে না, তখন টানেল তার কাজ করছে এবং সমাধানটি রিজলভার ক্রমে, সার্চ ডোমেইনে বা কনটেইনারের নিজের কনফিগারেশনে।

সম্পর্কিত নিবন্ধ