اشتراک محلی Samba پس از اعمال DNS توسط OpenVPN ناپدید شد

Samba اشتراک‌های محلی را در همان لحظه‌ای که OpenVPN متصل می‌شود از دست می‌دهد، و تونل تقریباً هرگز علت نیست. اتصال درست است، NAS روشن است، و resolver‌ای که تونل نصب کرده به پرسش‌هایی درباره نامی پاسخ می‌دهد که هرگز آن را ندیده است. Samba در ابتدای ترتیب جست‌وجوی خود از آن resolver می‌پرسد، پاسخ را باور می‌کند و به نشانی وصل می‌شود که هیچ‌چیز در آن گوش نمی‌دهد. درست کردن اشتراک یعنی درست کردن پاسخ، نه اتصال.

پنج بررسی، به ترتیبی که در هر گام بیشترین احتمالات را حذف می‌کند.

چه کسی برای نام کوتاه پاسخ می‌دهد

از سیستم‌عامل بپرسید، نه از مدیر فایل. resolvectl status سرورهای DNS متصل به هر پیوند را چاپ می‌کند و مشخص می‌کند کدام پیوند مسیر پیش‌فرض است، و پرس‌وجوی نام کوتاه سروری را که پاسخ داده گزارش می‌کند. آن را یک بار برای نام NAS و یک بار برای نامی که می‌دانید در دامنه دفتر وجود دارد اجرا کنید. اگر دو پاسخ از سرورهای متفاوت بیایند، شکاف را پیدا کرده‌اید.

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

چرا Samba پاسخ اشتباه را باور می‌کند

Samba نام‌ها را از طریق توالی ثابتی که name resolve order تعیین می‌کند حل می‌کند. در بیشتر توزیع‌ها مقدار پیش‌فرض شامل host است، یعنی DNS، و پیش از سازوکارهای فقط شبکه محلی مانند پخش NetBIOS اجرا می‌شود. بنابراین تونلی که resolver تحمیل می‌کند حق اولین رد را برای هر نام اشتراک می‌گیرد، از جمله نام‌های تک‌برچسبی که هرگز نباید ساختمان را ترک می‌کردند.

معمولاً نام ناشناخته پاسخ منفی برمی‌گرداند و سازوکار بعدی نوبت می‌گیرد. برخی resolver‌ها، به‌ویژه resolver‌های ISP مصرف‌کننده و عمومی، به نام‌های ناشناخته با صفحه جست‌وجو یا نشانی تبلیغاتی پاسخ می‌دهند. آن پاسخ برای کتابخانه resolver مانند موفقیت به نظر می‌رسد، پس Samba جست‌وجو را متوقف می‌کند و نشانی‌ای را می‌گیرد که هیچ ارتباطی با شبکه شما ندارد.

نتیجه اشتراکی است که بدون پنجره خطا ناپدید می‌شود. هیچ‌چیز در آن توالی خرابی مسیریابی VPN نیست، به همین دلیل ping به NAS هنوز کار می‌کند در حالی که مرور به آن کار نمی‌کند.

دو تعمیر با دامنه متفاوت

تعمیر محدود resolver تحمیلی را نگه می‌دارد و تغییر می‌دهد که Samba اجازه دارد چه چیزی از آن بپرسد. دو خط به پیکربندی Samba که دیمن واقعاً می‌خواند اضافه کنید، سپس سرویس را دوباره راه‌اندازی کنید:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

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

تعمیر گسترده علت را حذف می‌کند: تحمیل resolver‌ای که به نام‌هایی که مالک آن‌ها نیست پاسخ می‌دهد را متوقف کنید، یا سیاست DNS تقسیم‌شده را تحمیل کنید تا فقط پسوندهای دفتر به resolver دفتر برسند. این پاسخ بلندمدت بهتر در شبکه مدیریت‌شده است چون از مرورگر و مدیر بسته هم محافظت می‌کند، اما به دسترسی مدیریتی در سمت سرور نیاز دارد و کلاینتی که از تنظیمات تحمیلی پیروی می‌کند.

یکی را آگاهانه انتخاب کنید. تغییر resolver حل نام را برای همه برنامه‌ها همزمان تغییر می‌دهد، که یک رکورد تغییر است، نه ویرایشی برای تماس پشتیبانی.

پسوند می‌تواند همه‌چیز را توضیح دهد

اگر کلاینت پسوند جست‌وجو هم تحمیل کند، نام محلی کوتاه پیش از پرس‌وجو به دامنه دفتر بازنویسی می‌شود. آن‌گاه resolver اصلاً دروغ نمی‌گوید: پرسش منصفانه‌ای درباره نام دفتر از او شد و پاسخ درست داد. برای تشخیص این مورد از حالت نشانی تبلیغاتی، نام پرس‌وجوشده را در خروجی resolver بخوانید، چون هر دو خرابی در مدیر فایل یکسان به نظر می‌رسند.

راه‌حل اینجا یا استفاده از نام محلی کامل است یا افزودن قاعده DNS تقسیم‌شده‌ای که مالک پسوند محلی باشد. هیچ‌کدام نیاز به دست زدن به Samba ندارد.

آن را پس از اتصال دوباره ثابت کنید

سه نام را در یک نشست آزمایش کنید: اشتراک محلی با نام کوتاه، یک میزبان دفتر با نام، و یک وب‌سایت معمولی. اگر اولی کار کند و دومی بشکند، تعمیر ایراد را جابه‌جا کرده نه حذف. اگر سومی بشکند، تغییر resolver فراتر از قصد رفته و هر جست‌وجو اکنون مشکوک است.

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

اگر اشتراک پس از همه پنج بررسی هنوز شکست می‌خورد، پیش از تغییر هر چیز دیگری پرس‌وجوی دقیق و پاسخ دقیق را ثبت کنید. آن دو خط خرابی resolver را از نامی که واقعاً وجود ندارد جدا می‌کند، و سریع‌ترین یادداشت تحویل است که می‌توانید بنویسید.