اشتراک SMB فقط از طریق VPN ناموفق است: امضا یا تداخل زیرشبکه؟
اشتراکی که در LAN فعال است ممکن است فقط از طریق تونل ناموفق شود. رد امضا، زیرشبکه هم‌پوشان و نشست SMB قدیمی را از هم جدا کنید.
درایو نگاشت‌شده‌ای که در دفتر کار می‌کند و در خانه مهلتش تمام می‌شود، به‌تنهایی تقریباً هیچ اطلاعات مفیدی به شما نمی‌دهد. تونل آشکارا بسته‌ها را منتقل می‌کند، وگرنه هیچ چیزی به سرور نمی‌رسید. آنچه شکست خورده یکی از سه لایه است: نام به نشانی نادرست حل شده، کلاینت از امضای نشست خودداری کرده، یا نشست قدیمی از اتصالی که آن را حمل می‌کرد بیشتر عمر کرده است. هر یک تعمیر متفاوتی دارد و دو مورد از سه مورد سمت کلاینت است.
سه خرابی یک خطا را حمل می‌کنند
حرف درایو نمی‌گوید کدام لایه شکسته است و متن خطا معمولاً به‌قدری کلی است که به هر سه می‌خورد. آن‌ها را با دو پرسش سریع جدا کنید: آیا سرور روی نشانی IP خود پاسخ می‌دهد و آیا پورت 445 اتصالی می‌پذیرد؟
این پاسخ‌ها جدول تصمیم به‌جای حدس تولید می‌کنند. اگر IP کار کند و نام نکند، به حل نام اشاره دارد. اگر هر دو کار کنند و ورود رد شود، به امضا اشاره دارد. اگر هر دو کار کنند و خواندن یک فایل پس از قطع تونل معلق شود، به یک نشست قدیمی اشاره دارد.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
به همین ترتیب پیش بروید، زیرا نامی که به میزبان اشتباه حل شود هر آزمون بعدی را بی‌معنا می‌کند.
پیش از دست زدن به اشتراک، نام را حل کنید
اگر سرور روی نشانی خود پاسخ می‌دهد و نام اشتراک مهلتش تمام می‌شود، تونل کار خود را می‌کند و کلاینت جای اشتباهی را می‌گردد. در دسترسی از راه دور، دو علت بیشتر این را توضیح می‌دهد.
نخستین تداخل نشانی است. وقتی دفتر از 192.168.70.0/24 استفاده می‌کند و روتر خانه همان محدوده را می‌دهد، نام میزبانی که به 192.168.70.20 حل می‌شود می‌تواند به دستگاهی محلی اشاره کند نه سرور پشت تونل. Windows آنگاه ممکن است درخواست را محلی بفرستد، مسیر را رد کند، یا آن را به چاپگری حل کند که تصادفاً آن نشانی را دارد. تعمیر، شماره‌گذاری دوباره یک سمت است، نه افزودن مسیر دیگر.
دومین محدوده DNS است. آداپتور VPN بدون سرور DNS داخلی، یا با سروری که از طریق تونل در دسترس نیست، نام‌های کوتاه را به یک تحلیلگر عمومی می‌فرستد. ورودی‌های DNS آداپتور را بخوانید و پیش از دست زدن به اشتراک، نام داخلی را مستقیماً بپرسید:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15اگر آن پرس‌وجو نشانی مورد انتظار را برگرداند، حل نام روشن شده و مشکل بالاتر در پشته است.
شرط امضا را در هر دو سر بخوانید
سروری قابل دسترس که هر ورودی را رد می‌کند نشانه ناسازگاری خط‌مشی است نه خرابی شبکه. Windows می‌تواند امضای SMB را روی کلاینت الزامی کند و سرور یا NAS که امضا نمی‌کند نمی‌تواند نشست را کامل کند، هر قدر تونل سالم باشد.
می‌توانید تنظیم کلاینت را بدون جست‌وجو در ویرایشگر خط‌مشی بخوانید:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionمقدار متناظر سمت سرور در پیکربندی SMB سرور است و این دو باید همخوان باشند. در یک مورد گزارش‌شده، شرط روی کلاینت با خط‌مشی محلی فعال بود در حالی که سرور اصلاً امضا نمی‌کرد؛ غیرفعال کردن آن و اجرای gpupdate /force اشتراک را فوراً بازگرداند. این گامی تشخیصی برای تأیید علت است، نه اصلاحی دائمی.
ترجیح دهید امضا را در هر دو سر فعال کنید جایی که سرور پشتیبانی می‌کند. تغییر یک تنظیم امنیتی برای کار کردن یک اشتراک باید با مقدار پیشین و دلیل ثبت شود تا کسی مجبور نشود در ممیزی بعدی آن را دوباره کشف کند.
پیش از تنظیم زمان‌سنج‌ها، نشست قدیمی را پاک کنید
اشتراکی که فقط پس از افتادن VPN و اتصال دوباره معلق می‌شود معمولاً نشستی را نگه می‌دارد که سرور قبلاً دور انداخته است. سرور نشست‌های بیکار SMB را طبق زمان‌سنج Autodisconnect زیر LanmanServer\Parameters می‌بندد که به‌طور پیش‌فرض 15 دقیقه است، در حالی که کلاینت SessTimeout خودش را زیر LanmanWorkstation\Parameters دارد. قطعی طولانی‌تر از این مقادیر هر سر را با تصوری متفاوت از نشست رها می‌کند.
آن را در ترتیبی ثابت بازتولید کنید تا نتیجه معنایی داشته باشد: تونل را وصل کنید، اشتراک را باز کنید، تونل را دو دقیقه قطع کنید، آن را بازگردانید و سپس بخواهید فایلی بخوانید. اگر اتصال خودبه‌خود بازیابی شد، زمان‌سنج‌ها را رها کنید. اگر تا اتصال دوباره معلق ماند، پس از برپا شدن تونل اشتراک را دوباره وصل کنید به‌جای وصل کردن آن پیش از وجودش، و بررسی کنید که آیا راهنمای اتصال دوباره تلاش می‌کند.
افزایش مهلت‌ها گام آخر معقولی برای پیوندی ناپایدار است، اما نشانه را درمان می‌کند. کلاینتی که بیشتر منتظر نشستی می‌ماند که سرور فراموش کرده، هنوز منتظر است.
با خواندن یک فایل از طریق اتصال و سپس قطع و بازگرداندن یک‌بار دیگر تونل تمام کنید. آن آزمون پذیرش هر سه لایه را یکجا پوشش می‌دهد و تنها آزمونی است که با آنچه کاربر واقعاً انجام می‌دهد مطابقت دارد.