چرا Samba کلاینت‌های VPN را که به سرور می‌رسند رد می‌کند

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

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

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

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

نشانی مبدأیی را که smbd واقعاً می‌بیند پیدا کنید

با دسترسی مسیریابی‌شده سرور معمولاً نشانی کلاینت را از استخر VPN می‌بیند. با ترجمه مبدأ روی دروازه، در عوض نشانی LAN دروازه را می‌بیند، و هر کلاینت پشت آن دروازه غیرقابل تشخیص می‌شود.

این تفاوت تعیین می‌کند که یک ورودی فهرست مجاز سیاست است یا یک حفره. اجازه دادن به یک نشانی دروازه ترجمه‌شده همه کسانی را که پشت آن هستند می‌پذیرد، که قاعده‌ای برای هر کلاینت به‌ندرت می‌خواست بیان کند. منبع را از سرور بخوانید، نه از تصور کلاینت درباره نشانی خودش. ضبط روی رابط سرور ارزان‌ترین راه دیدن آن است، و همان ضبط ثابت می‌کند که بسته اصلاً رسیده است یا نه. ضبط را با تعداد بسته محدود کنید و وقتی دانستید کدام کلاینت را دنبال می‌کنید یک فیلتر میزبان اضافه کنید. جدول نشست Samba نیمه دیگر پاسخ است: در smbstatus -b ستون کلاینت در هر سطر نشست همان همتایی است که smbd ثبت کرده، و این سریع‌ترین تأیید نشانی‌ای است که واقعاً به سرویس رسیده است.

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

فهرست مجاز را همان‌گونه که Samba می‌خواند بخوانید

تنظیم hosts allow فهرستی از نشانی‌ها، شبکه‌ها یا نام‌ها می‌گیرد و می‌تواند به‌صورت سراسری یا درون یک اشتراک ظاهر شود. دو ورودی که برای شما معادل به نظر می‌رسند ممکن است برای تجزیه‌کننده معادل نباشند، پس پیکربندی مؤثر چیزی است که باید بررسی شود. این یعنی نمای ادغام‌شده، نه فایلی که تصادفاً ویرایش کردید.

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

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

فایلی را تغییر دهید که از راه‌اندازی مجدد جان سالم می‌برد

روی یک میزبان معمولی Linux مسیر پیکربندی ثابت است و سرویس هنگام راه‌اندازی مجدد آن را دوباره می‌خواند. روی یک مسیریاب یا دستگاه، smb.conf در حال اجرا اغلب هنگام بوت تولید می‌شود، و ویرایش دستی در راه‌اندازی مجدد بعدی ناپدید می‌شود. از سازوکار سفارشی‌سازی پشتیبانی‌شده دستگاه استفاده کنید، که معمولاً فایل پیکربندی خودش است.

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

ثبت کنید کدام فایل را تغییر دادید و چه چیزی آن را دوباره می‌سازد، تا نفر بعدی تشخیص را تکرار نکند.

یک کلاینت مجاز و یک کلاینت مستثنا را آزمایش کنید

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

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

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