Сторінка «Мережа» у Проводнику показує пристрої, які оголосили себе в локальному сегменті, а маршрутизований тунель не передає жодного з таких оголошень. Тому сервер може бути цілком доступним, поки вікно перед користувачем залишається порожнім. Іменований шлях UNC взагалі не залежить від виявлення, і рішення полягає в тому, щоб ім'я розв'язувалося, а порт відповідав. Порожнє вікно — симптом неправильного рівня, а не зламаної спільної папки.

Виявлення — це не те саме, що доступність

Windows знаходить сусідні машини через протоколи, розраховані на широкомовний домен, і потім показує знайдене як список для зручності. Нічого з цього списку не потрібно для доступу до файлів через SMB. Клієнт, який знає ім'я сервера і може достукатися до TCP 445, відкриє спільну папку незалежно від того, чи з'явиться машина колись у розділі «Мережа».

Два рівні відмовляють незалежно, тому «я його не бачу» і «я не можу його відкрити» заслуговують на різні перевірки. Погляд на список говорить про виявлення; відкриття шляху говорить про службу.

Назвіть сервер, перш ніж підключати спільну папку

Опублікуйте файловий сервер у DNS з адресою, яку він має на дальньому боці, і спрямуйте майданчик клієнта на резолвер, здатний відповідати за цю зону. Повне доменне ім'я позбавляє залежності від локального списку суфіксів пошуку — звичайної причини, чому коротке ім'я працює на одному майданчику і не працює на іншому.

Якщо середовище використовує Active Directory, розв'язання імен також входить до автентифікації: клієнт має достукатися до контролера домену для Kerberos, а годинник, що надто відхилився, призведе до збою обміну квитками. Це інша проблема, ніж доступність SMB, і виглядає вона як помилка облікових даних. Перевірте контролер домену, перш ніж вводити пароль знову.

LayerWhat it needsSymptom when missing
Name resolutionA DNS answer for the server namePath cannot be found, ping by IP still works
TransportTCP 445 open in both directionsConnection times out or is refused
AuthenticationA reachable domain controller and correct clockAccess is denied after the port connects
AuthorizationShare permission and filesystem permissionThe share opens but the folder is inaccessible

Маршрутизація і фільтрація в обидва боки

Тунелю між майданчиками потрібен віддалений префікс у локальній таблиці маршрутизації і локальний префікс у віддаленій, а міжмережевий екран з кожного боку має пропускати трафік, що надходить. Однобічне налаштування дає з'єднання, яке відкривається і ніколи не відповідає, що користувачі описують як повільну спільну папку. Спочатку перевірте власні лічильники тунелю. Якщо пакети виходять і нічого не повертається, шукайте зворотний маршрут або віддалений фільтр.

У WireGuard дозволені IP-адреси партнера і маршрути операційної системи мають узгоджуватися з цим проєктом. Тунель переносить пакети; він не створює записи DNS і не надає дозволів на спільну папку з жодного боку.

Будуйте правило міжмережевого екрана за реальною вихідною мережею, яка буде підключатися, і запишіть виняток. Якщо проєкт десь на шляху транслює адреси, правило має використовувати трансльоване джерело, а початкова адреса клієнта більше не видна в журналах.

Автентифікуйтеся, потім підключіть диск

Проходьте рівні командами, а не вікном Проводника:

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 має залишатися на приватному шляху, а не на переадресації в інтернет. Дайте користувачам керований ярлик або підключений диск до затвердженого імені, і порожня сторінка «Мережа» перестане мати значення.

Схожі статті