آپ کا 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 کو جلدی واپسی کی کارروائی سے آگے لے جائیں، اور اسے ترتیب کے انتظام سے بدلیں۔ ہاتھ سے کی گئی ترمیم اگلی 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 کا مسئلہ ہے۔ غیر حل شدہ نام ریزولور کا مسئلہ ہے۔ اور تصدیق کے بعد اجازت کی غلطیاں واپس کرنے والا ماؤنٹ دونوں میں سے کوئی نہیں، اس لیے سیشن قائم ہونے کے بعد نیٹ ورک سوال دوبارہ نہ کھولیں۔

نتیجہ ثبوت جتنا ہی تنگ رکھیں۔ جب پتہ چلے اور نام نہ چلے، ٹنل اپنا کام کر رہا ہے، اور ترمیم ریزولور ترتیب، تلاش ڈومین یا کنٹینر کی اپنی ترتیب میں ہے۔