درایو مپ‌شده روی VPN سایت: DNS، SMB و مسیر UNC
کشف شبکه از پیوند مسیریابی‌شده عبور نمی‌کند، اما یک مسیر UNC نام‌دار عبور می‌کند. DNS را به سرور نشانه بگیرید، SMB را در هر دو جهت باز کنید و سپس درایو را مپ کنید.
صفحه شبکه در Explorer دستگاه‌هایی را نشان می‌دهد که خود را در بخش محلی اعلام کرده‌اند، و تونل مسیریابی‌شده هیچ‌یک از این اعلان‌ها را حمل نمی‌کند. به همین دلیل سرور می‌تواند کاملاً در دسترس باشد در حالی که پنجره پیش روی کاربر خالی بماند. یک مسیر UNC نام‌دار اصلاً به کشف وابسته نیست، و راه‌حل این است که نام حل شود و درگاه پاسخ بدهد. پنجره خالی نشانه لایه اشتباه است، نه اشتراک خراب.
کشف با دسترسی یکی نیست
ویندوز رایانه‌های نزدیک را با پروتکل‌هایی که برای دامنه پخش طراحی شده‌اند پیدا می‌کند و سپس یافته‌ها را به‌صورت فهرستی برای راحتی نشان می‌دهد. هیچ چیز در آن فهرست برای دسترسی به فایل با SMB لازم نیست. کلاینتی که نام سرور را می‌داند و به TCP 445 می‌رسد، اشتراک را باز می‌کند، چه دستگاه هرگز در شبکه ظاهر شود چه نه.
دو لایه مستقل از هم شکست می‌خورند، به همین دلیل "آن را نمی‌بینم" و "نمی‌توانم بازش کنم" شایسته آزمون‌های متفاوتی هستند. نگاه به فهرست درباره کشف می‌گوید؛ باز کردن مسیر درباره سرویس.
پیش از مپ کردن اشتراک به سرور نام بدهید
سرور فایل را در DNS با نشانی‌ای که در آن سوی پیوند دارد منتشر کنید و سایت کلاینت را به یک resolver نشانه بگیرید که می‌تواند برای آن ناحیه پاسخ دهد. یک نام کاملاً واجد شرایط از وابستگی به فهرست پسوندهای جست‌وجوی محلی جلوگیری می‌کند، که دلیل معمول کار کردن یک نام کوتاه در یک سایت و شکست آن در سایت دیگر است.
اگر محیط از Active Directory استفاده می‌کند، حل نام بخشی از احراز هویت هم هست: کلاینت باید برای Kerberos به یک کنترل‌کننده دامنه برسد، و ساعتی که بیش از حد از هم‌زمانی خارج شده باشد تبادل بلیت را شکست می‌دهد. این مشکلی متفاوت از دسترسی SMB است و شبیه خطای اعتبارنامه به نظر می‌رسد. پیش از وارد کردن دوباره رمز عبور، کنترل‌کننده دامنه را آزمایش کنید.
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
مسیریابی و فیلتر در هر دو جهت
تونل میان سایت‌ها به پیشوند دور در جدول مسیریابی محلی و پیشوند محلی در جدول دور نیاز دارد، و دیوار آتش در هر سمت باید ترافیک ورودی را مجاز کند. پیکربندی یک‌طرفه اتصالی می‌سازد که باز می‌شود و هرگز پاسخ نمی‌دهد، چیزی که کاربران آن را کندی اشتراک توصیف می‌کنند. نخست شمارنده‌های خود تونل را بررسی کنید. اگر بسته‌ها بیرون می‌روند و چیزی برنمی‌گردد، مسیر بازگشت یا فیلتر دور را جست‌وجو کنید.
در WireGuard، نشانی‌های IP مجاز همتا و مسیرهای سیستم‌عامل باید با آن طراحی هم‌خوان باشند. تونل بسته‌ها را حمل می‌کند؛ اما رکوردهای DNS یا مجوزهای اشتراک فراهم نمی‌کند در هیچ‌یک از دو سمت.
قاعده دیوار آتش را بر شبکه مبدأ واقعی که متصل خواهد شد بنا کنید و استثنا را بنویسید. اگر طراحی جایی در مسیر نشانی‌ها را ترجمه می‌کند، قاعده باید از مبدأ ترجمه‌شده استفاده کند، و نشانی اصلی کلاینت دیگر در گزارش‌ها دیده نمی‌شود.
احراز هویت کنید، سپس درایو را مپ کنید
لایه‌ها را با فرمان‌ها پایین بروید، نه با پنجره Explorer:
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:noفرمان دوم مسیر TCP را اثبات می‌کند، نه حق خواندن چیزی را. فرمان سوم جایی است که احراز هویت و مجوزدهی اعمال می‌شود، و شکست در آنجا باید شما را به مجوزهای اشتراک و سیستم فایل بفرستد، نه بازگشت به روتر.
امضای SMB و سیاست احراز هویت موجود را دست‌نخورده نگه دارید. فعال‌سازی دوباره SMB1 یا عبور دادن پخش کشف از تونل برای یک مسیر صریح لازم نیست، و TCP 445 باید روی مسیر خصوصی بماند نه روی یک ارسال رو به اینترنت. به کاربران یک میانبر مدیریت‌شده یا درایو مپ‌شده به نام تأییدشده بدهید، و صفحه خالی شبکه دیگر اهمیتی ندارد.