نصب CIFS شما از طریق VPN به دلیل ترتیب nsswitch شکست می‌خورد

تونل برپاست. سرور فایل به ping با نشانی پاسخ می‌دهد. سپس mount.cifs با نام میزبان مدتی همان‌جا می‌ماند و گزارش می‌دهد که میزبان در دسترس نیست، و شما شروع به بازسازی پروفایل VPN می‌کنید که هرگز مشکل نبود. در Linux، glibc نام را پیش از آنکه بستهٔ SMB وجود داشته باشد حل می‌کند، و ترتیب در آن resolver می‌تواند جست‌وجو را پیش از آنکه هرگز از DNS پرسیده شود پایان دهد. این مسیری است که می‌روم، با شروع از فرمانی که شکست خورد، نه از سمت کلاینت.

شکست را در جای درست بخوانید

دو ابزار مسیرهای متفاوتی به یک نام می‌روند و مقایسهٔ آن‌ها یک فرمان می‌ارزد. getent در پشتهٔ سرویس‌های نام پیکربندی‌شده می‌گردد؛ host و dig مستقیماً DNS را می‌پرسند و آن پشته را نادیده می‌گیرند. اگر پرس‌وجوی مستقیم نشانی برگرداند و getent چیزی برنگرداند، سرور DNS در دسترس است و تنظیمات resolver شماست که شکست می‌خورد.

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

فرمان سوم داور است: منبع DNS را تحمیل می‌کند و بقیهٔ پشته را رد می‌کند. وقتی آن کار می‌کند و getent ساده نه، ثابت کرده‌اید که ترتیب مقصر است، نه تونل و نه سرور.

خط hosts دنباله‌ای است که زود متوقف می‌شود

resolver در glibc فایل /etc/nsswitch.conf را می‌خواند و مدخل hosts: را از چپ به راست می‌پیماید. بسیاری از توزیع‌ها خطی می‌فرستند که در آن جست‌وجوی multicast اول می‌آید و یک کنش بازگشت زودهنگام به آن پیوند خورده است. کنش تزئینی نیست: وقتی mDNS پاسخ “not found” می‌دهد، [NOTFOUND=return] کل جست‌وجو را پایان می‌دهد، پس نام سازمانی هرگز به resolverی که VPN تحمیل کرده فرستاده نمی‌شود. هیچ چیز آن را ثبت نمی‌کند، چون هیچ پرس‌وجویی فرستاده نشد که resolver بتواند ردش کند. به همین دلیل نصب معطل به نظر می‌رسد و سپس میزبان در دسترس نبودن را گزارش می‌دهد.

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

DNS را پیش از کنش بازگشت زودهنگام بگذارید، نه اینکه mDNS را حذف کنید، و آن را از طریق مدیریت پیکربندی تغییر دهید. ویرایش دستی تا build بعدی ایمیج می‌ماند و سپس همان تیکت از ماشین دیگری می‌آید که هیچ خاطره‌ای از اصلاح ندارد.

resolver یک دامنهٔ جست‌وجو نیست

حل نام همچنین نیاز دارد که نام امتحان شود. نامی غیرکیفی مانند fileserver تنها زمانی fileserver.corp.example می‌شود که دامنهٔ جست‌وجو به رابطی که پرس‌وجو را حمل می‌کند پیوند بخورد. VPNی که سرور DNS را بدون فهرست جست‌وجو تحمیل می‌کند شکاف بسیار مشخصی می‌سازد: نام کاملاً کیفی حل می‌شود و هر نام کوتاه شکست می‌خورد.

پیش از ویرایش پروفایل هر دو شکل را بیازمایید، چون دو شکست به دو جهت متفاوت اشاره می‌کنند. روی میزبان دارای systemd-resolved، پیوند تونل سرورها و دامنه‌های مسیریابی خودش را دارد، پس پیوند را بخوانید نه فایل سراسری.

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

اگر پرس‌وجو به پیوندی نسبت داده شود که تونل را حمل نمی‌کند، دامنهٔ مسیریابی غایب است هرچند نشانی DNS حاضر است. این یک مشکل سیاست در پیکربندی resolved است، نه مشکل مسیریابی در تونل.

کانتینرها نسخهٔ خودشان از پاسخ را حمل می‌کنند

کانتینری که از یک ایمیج عمومی ساخته می‌شود معمولاً یک resolv.conf ثابت می‌آورد. تغییرات resolver روی میزبان به آن نمی‌رسد و دامنهٔ جست‌وجو هم نه، پس کار buildی که اشتراکی را از طریق تونل نصب می‌کند شکست می‌خورد در حالی که همان فرمان بیرون کانتینر کار می‌کند. تنظیمات DNS و جست‌وجوی خودش را در فایل compose یا در آرگومان‌های اجرا به کانتینر بدهید، نه فقط در پروفایل میزبان.

پیش از سرزنش ایمیج، داخل کانتینر بررسی کنید. دو فرمان کل تشخیص را در چند ثانیه بازتولید می‌کنند و دومی ثابت می‌کند کدام resolver واقعاً پاسخ داده است.

تنها آن‌گاه به اشتراک و فیلتر نگاه کنید

وقتی نام حل شد، شکست‌های باقی‌مانده شبکه‌ای معمولی‌اند. 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 در طرف مقابل است. نام حل‌نشده مشکل resolver است. و نصبی که احراز هویت می‌کند اما خطاهای دسترسی برمی‌گرداند هیچ‌یک نیست، پس وقتی نشست برقرار شد پرسش شبکه را دوباره باز نکنید.

نتیجه را به باریکی شواهد نگه دارید. وقتی نشانی کار می‌کند و نام نه، تونل کار خودش را می‌کند و اصلاح به ترتیب resolver، دامنهٔ جست‌وجو یا پیکربندی خود کانتینر تعلق دارد.