Samba روی یک نشانی VPN: چرا شنونده ناپدید می‌شود

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

اشتراک تا وقتی تونل دوباره راه‌اندازی شود کار می‌کند

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

ping ممکن است هنوز موفق شود اگر نشانی جدید به ICMP پاسخ دهد، و به همین دلیل در حالی که اشتراک مرده است دسترسی‌پذیری خوب به نظر می‌رسد. همان یک موفقیت گمراه‌کننده است که مردم را به دیوار آتش می‌فرستد.

دسترسی‌پذیری یک نشانی اتصال نیست

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

نشانی از استخر VPN هم به‌طور خودکار نشانی اتصال محلی نیست. به یک کارخواه تعلق دارد، نه به کارساز فایل. ping آزمون بدی برای سرویس فایل است.

این مالکیت‌ها را در مستندات هم جدا نگه دارید. تغییر آینده در استخر VPN نباید ویرایش Samba را لازم کند، و تغییر مجوز اشتراک نباید راه‌اندازی دوباره تونل را لازم کند.

در عوض به یک نشانی پایدار گره بزنید

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

اگر ناچار باید به تونل گره بزنید، قرارداد نسخهٔ نصب‌شده را بفهمید. پارامترهای interfaces و bind interfaces only یک چیز نیستند، و مستندات اتصال درباره واسط‌های متناوب هشدار می‌دهد. مدیریت پویای شنونده روی برخی سکوها وجود دارد، اما این توانایی‌ای است که باید بررسی شود، نه فرض. جدول را پیش و پس از نوسان بخوانید و دو خروجی را مقایسه کنید.

ss -ltnp | grep ':445'

اتصال دوباره را بیازمایید، نه چراغ سبز را

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

smbclient -L //files.corp.example -U alice

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