Сценарій завжди однаковий: ви відкриваєте Провідник файлів, клікаєте Мережа, а там—пустка. Тим часом ви можете пропінгувати інший ПК, серфити інтернет і Teams радо гризе CPU, наче за кожен цикл платять. То чому Windows «не бачить» машину, яка очевидно поруч?
Тому що «мережеве виявлення» — це не одна річ. Це купа служб, правил брандмауера, шляхів резолюції імен, спадкова поведінка SMB-браузингу і те, що ваш роутер вирішив сьогодні. Ми зробимо це нудним знову—в хорошому сенсі.
Що «мережеве виявлення» насправді означає (і чому воно брешe)
Коли користувачі кажуть «Windows не бачить інші ПК», вони зазвичай мають на увазі одне з наступного:
- Перегляд «Мережа» у Провіднику порожній або відсутні конкретні комп’ютери.
- Не вдається змонтувати диск за ім’ям (наприклад,
\\FILES01\Share). - Доступ за IP працює (наприклад,
\\192.168.1.50\Share), але імена — ні. - Ping працює, але SMB не працює.
- SMB працює, але комп’ютер не показується у списках браузингу.
Це різні режими відмови. Підходьте до них по-різному.
Неприємна правда: папка Мережа у Провіднику файлів — це не надійна система моніторингу. Це UI, що підживлюється механізмами виявлення, які можуть бути заблоковані профілями мережі, брандмауером, станом служб або сучасною безпековою політикою. Вона може помилятися навіть коли сумісний шар файлообміну працює.
Тож мета — не «змусити з’явитися значки». Мета:
- Імена хостів стабільно резолюються.
- Порти SMB доступні у потрібній мережі.
- Шари доступні з правильною автентифікацією.
- Виявлення працює там, де треба (зазвичай Private LAN), і блокується всюди, де небезпечно (гостьовий Wi‑Fi в аеропорту тощо).
Цитата, яку варто приліпити на монітор: «Надія — це не стратегія.» — Gordon R. Sullivan. (Якщо ви керуєте production-системами, ви вже вчили це дорогою ціною.)
Швидка діагностика (перевірте це спочатку)
Це послідовність «виручити мене за п’ять хвилин». Запустіть на ПК, який не бачить інших, і, за потреби, на цільовому ПК, що повинен бути видимим.
1) Підтвердьте, що ви на правильному мережевому профілі
Якщо встановлено Public, виявлення має бути обмежене за замовчуванням. Виправте це перед тим, як тицяти інші налаштування.
2) Перевірте резолюцію і доступність
- Спробуйте
ping TARGETіping TARGET_IP. - Спробуйте
Test-NetConnection TARGET -Port 445і за IP.
Якщо IP працює, а ім’я — ні: це проблема DNS/LLMNR/mDNS/NetBIOS, а не «шарінгу».
3) Перевірте групи правил брандмауера і служби виявлення
Windows може гордо сказати «Мережеве виявлення увімкнено», тоді як правила брандмауера вимкнені або служби Function Discovery зупинені.
4) Ігноруйте Провідник і перевіряйте SMB напряму
Відкрийте \\TARGET\Share. Якщо працює, у вас проблема з браузингом/виявленням, а не з файлообміном.
5) Якщо це корпоративний домен — припускайте GPO
Особливо якщо «вчора працювало». Групова політика може повернути служби, правила брандмауера і поведінку резолюції імен. Не бійтесь її вручну змінювати — виправляйте політику.
Цікаві факти та коротка історія (ви перестанете звинувачувати не те)
Трохи контексту допоможе, бо Windows‑мережі — це музей, де експонати ще й досі підключені.
- Традиція «browse list» походить від NetBIOS/Computer Browser, спадкової системи, яка використовувала трансляційні вибори, щоб визначити, хто формує список машин. Ось чому вона була нестабільною в мультипідмережах.
- SMBv1 був пов’язаний зі старим браузингом. Коли SMBv1 масово відключили з міркувань безпеки, багато хто сприйняв порожчу мережу як «мережа зламалась».
- WS‑Discovery (WSD) став сучаснішим методом виявлення для пристроїв і деяких сценаріїв Windows, але сильно залежить від брандмауера і мультикасту.
- LLMNR існує тому, що DNS не завжди присутній у малих мережах. Це зручно, але також популярна ціль для перехоплення облікових даних у ворожих середовищах.
- mDNS вже не «лише для Apple». Windows підтримує mDNS в сучасних збірках, і воно з’являється в змішаних домашніх мережах частіше, ніж багато хто думає.
- Мережеві профілі (Public/Private/Domain) введені, щоб зменшити «я підключився до кафе Wi‑Fi і відкрив свої шари для незнайомців». Відмови виявлення часто є функцією, а не багом.
- SMB поверх TCP/445 замінив NetBIOS over TCP/139 у більшості сучасних середовищ, але інструменти й звички іноді все ще лізуть у старий стек.
- Погляд «Мережа» у Провіднику навмисне консервативний у сучасних Windows. Це не канонічний каталог; це зручний UI, який віддає пріоритет безпеці і мінімізації шуму.
Основні принципи: профіль, брандмауер, служби, імена, SMB
1) Мережевий профіль визначає початкову безпекову позицію
Якщо NIC встановлено як Public, Windows заблокує або обмежить трафік, що використовується для виявлення і файлообміну. Ви можете цілий день вмикати «Мережеве виявлення» в Налаштуваннях і все одно отримувати нестабільні результати, якщо базовий профіль неправильний.
2) Правила брандмауера важать більше за додаток Налаштувань
Windows має групи правил брандмауера, такі як Мережеве виявлення і Файли та принтери. Якщо вони вимкнені, виявлення не працюватиме. Якщо ввімкнені в неправильному профілі, ви можете випадково рекламувати свою машину там, де не слід.
3) Служби — це машинний зал
Дві служби найчастіше підозрювані:
- Function Discovery Provider Host (FDPHost)
- Function Discovery Resource Publication (FDResPub)
Якщо вони зупинені/вимкнені, ваша машина може не публікуватись і не виявляти інших надійно.
4) Резолюція імен — багатоголовий звір
Коли ви вводите \\TARGET, Windows може резолювати це ім’я через:
- DNS (найкращий варіант у керованих мережах)
- LLMNR
- mDNS
- NetBIOS name service (спадщина)
- Файл hosts (ручне перевизначення)
Різні середовища відключають різні методи (часто з міркувань безпеки). Ви маєте знати, на що спираєтесь.
5) SMB може працювати навіть коли виявлення зламане
Виявлення — це про знаходження ресурсів. SMB — це про підключення. Не плутайте їх. Якщо можете отримати доступ до \\IP\Share, ваш шар працює. Ви маєте справу з проблемою імен або списків браузингу.
Жарт #1: Мережева функція виявлення Windows — як офісні плітки: швидка, ненадійна і зупиняється, як тільки приходить юридичний відділ (іншими словами—брандмауер).
Практичні завдання з командами: діагностика і рішення
Ось реальні завдання, які можна виконати. Кожне містить: команду, що означає вивід, і яке рішення зробити далі. Запускайте їх у піднятому PowerShell, коли можливо.
Завдання 1: Перевірити мережевий профіль (Public vs Private)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-List Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name : Corp-WiFi
InterfaceAlias : Wi-Fi
NetworkCategory : Public
IPv4Connectivity: InternetЗначення: NetworkCategory : Public пояснює, чому виявлення і SMB можуть бути за умовчанням обмежені.
Рішення: Якщо це ваш довірений LAN — переключіть на Private. Якщо мережа справді ненадійна — не чекайте від виявлення, використовуйте VPN + DNS замість цього.
Завдання 2: Переключити мережу на Private (тільки якщо доречно)
cr0x@server:~$ powershell -NoProfile -Command "Set-NetConnectionProfile -InterfaceAlias 'Wi-Fi' -NetworkCategory Private; Get-NetConnectionProfile -InterfaceAlias 'Wi-Fi' | Select-Object InterfaceAlias,NetworkCategory"
InterfaceAlias NetworkCategory
-------------- ---------------
Wi-Fi PrivateЗначення: NIC тепер Private, отже Windows дозволить правила виявлення (якщо вони увімкнені) для цього профілю.
Рішення: Перетестуйте виявлення/SMB. Якщо тепер працює — ви боролись не з пакетною втратою, а з політикою.
Завдання 3: Підтвердити базову IP‑конфігурацію
cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias : Ethernet
IPv4Address : {192.168.10.21}
IPv4DefaultGateway : {192.168.10.1}
DnsServer : {192.168.10.10}Значення: У вас є IP, шлюз і DNS. Якщо DNS — випадковий IP роутера, резолюція імен може бути слабкою.
Рішення: Якщо DNS вказує не туди (або пустий) — виправте DHCP/DNS перед тим, як робити складні речі.
Завдання 4: Перевірити резолюцію імен через DNS
cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FILES01 -ErrorAction SilentlyContinue | Select-Object Name,IPAddress"
Name IPAddress
---- ---------
FILES01 192.168.10.50Значення: DNS може резолювати ім’я хоста. Це ідеально.
Рішення: Якщо це не вдається, вам потрібен робочий DNS, або доведеться відпиратись на LLMNR/NetBIOS/mDNS (які можуть бути вимкнені). Вирішіть, чи виправляти DNS (рекомендовано), чи приймати тимчасові хакі між вузлами.
Завдання 5: Перевірити досяжність порту SMB 445 (за іменем і за IP)
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection FILES01 -Port 445 | Select-Object ComputerName,RemoteAddress,TcpTestSucceeded"
ComputerName RemoteAddress TcpTestSucceeded
------------ ------------- ---------------
FILES01 192.168.10.50 TrueЗначення: TCP/445 доступний. Брандмауер і маршрути ймовірно дозволяють SMB.
Рішення: Якщо False, зупиніться. Виправте правила брандмауера на цілій машині, VLAN‑ізоляцію або налаштування роутера «гостьова мережа». Виявлення не виправить заблокований SMB.
Завдання 6: Якщо ім’я не працює, а IP працює — доведіть це
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 192.168.10.50 -Port 445 | Select-Object RemoteAddress,TcpTestSucceeded"
RemoteAddress TcpTestSucceeded
------------- ---------------
192.168.10.50 TrueЗначення: Сервіс досяжний; ваша проблема — резолюція імен або ідентичність (SPN/облікові дані), а не зв’язність.
Рішення: Виправте DNS або використовуйте запис у hosts як тимчасове рішення. Не вчіть користувачів постійно вводити IP.
Завдання 7: Перевірити необхідні служби виявлення
cr0x@server:~$ powershell -NoProfile -Command "Get-Service FDResPub,FDPHost,SSDPSRV,upnphost | Select-Object Name,Status,StartType"
Name Status StartType
---- ------ ---------
FDResPub Stopped Manual
FDPHost Running Automatic
SSDPSRV Stopped Manual
upnphost Stopped ManualЗначення: Якщо FDResPub зупинено, ваша машина може не публікувати себе для виявлення. Деякі середовища не потребують SSDP/UPnP; не вмикайте їх бездумно.
Рішення: У невеликій LAN, де потрібне виявлення, встановіть FDResPub в Automatic (Delayed Start) і запустіть її. В корпоративній мережі з жорсткою політикою — перевірте політику перш ніж змінювати.
Завдання 8: Запустити і встановити Function Discovery Resource Publication правильно
cr0x@server:~$ powershell -NoProfile -Command "Set-Service FDResPub -StartupType Automatic; Start-Service FDResPub; Get-Service FDResPub | Select-Object Name,Status,StartType"
Name Status StartType
---- ------ ---------
FDResPub Running AutomaticЗначення: Служба працює і збережеться після перезавантаження.
Рішення: Перевірте перегляд «Мережа» через хвилину. Якщо все ще порожньо — брандмауер або профіль досі неправильні, або мережа блокує мультикаст.
Завдання 9: Перевірити, що групи правил брандмауера увімкнені для профілю Private
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'Network Discovery' | Select-Object -First 5 DisplayName,Enabled,Profile | Format-Table -Auto"
DisplayName Enabled Profile
----------- ------- -------
Network Discovery (NB-Name-In) True Private
Network Discovery (NB-Datagram-In) True Private
Network Discovery (NB-Session-In) True Private
Network Discovery (SSDP-In) True Private
Network Discovery (UPnP-In) True PrivateЗначення: Правила виявлення увімкнені для Private. Якщо вони вимкнені — Windows не зможе «бачити» пристрої, що використовують ці методи.
Рішення: Увімкніть групу для Private, якщо бажаєте виявлення; залишайте вимкненою для Public.
Завдання 10: Увімкнути групи правил брандмауера (Мережеве виявлення + Файли та принтери)
cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayGroup 'Network Discovery' -Enabled True; Set-NetFirewallRule -DisplayGroup 'File and Printer Sharing' -Enabled True; 'done'"
doneЗначення: Це вмикає великий набір вхідних правил. Саме тому робити це слід лише в довірених Domain/Private профілях.
Рішення: Якщо після цього «все відновлюється», ви знайшли вузьке місце: конфігурацію брандмауера, імовірно керовану GPO у бізнес‑мережах.
Завдання 11: Переконатися, що SMB‑сервер увімкнений на цільовій машині
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess"
EnableSMB1Protocol EnableSMB2Protocol RejectUnencryptedAccess
------------------ ------------------ ------------------------
False True TrueЗначення: SMB2 увімкнено (добре). SMB1 вимкнено (теж добре, зазвичай). Деякі старі пристрої потребують SMB1; ставте це як задачу ізоляції, а не запит функції.
Рішення: Не вмикайте SMB1, якщо ви не ізолюєте той пристрій і не усвідомлюєте ризик. Краще оновити пристрій або використовувати інший протокол.
Завдання 12: Перелічити шари і переконатися, що ви не женетесь за неіснуючим шляхом
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select-Object Name,Path,Description | Format-Table -Auto"
Name Path Description
---- ---- -----------
IPC$ Remote IPC
Public C:\Shares\Public Common dropЗначення: Шар існує. Якщо користувачі не можуть до нього дістатися — це питання прав або автентифікації, а не виявлення.
Рішення: Підтвердіть дозволи на шар і NTFS ACL; перевірте, під яким обліковим записом аутентифікується користувач.
Завдання 13: Перевірити, що ви можете перерахувати ресурси через SMB (з боку клієнта)
cr0x@server:~$ powershell -NoProfile -Command "net view \\FILES01"
Shared resources at \\FILES01
Share name Type Used as Comment
---------- ---- ------- -------
Public Disk Common drop
The command completed successfully.Значення: Перегляд ресурсів через SMB, аутентифікація і перерахунок шарів пройшли успішно за ім’ям. Якщо Провідник все ще не показує його — ігноруйте Провідник. Ви працюєте.
Рішення: Навчіть користувачів закріплювати/монтирувати по UNC або картографувати диски через GPO/скрипт. Не покладайтесь на браузинг.
Завдання 14: Перевірити стан облікових даних/сесій якщо доступ дивний
cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use'"
New connections will be remembered.
Status Local Remote Network
-------------------------------------------------------------------------------
OK \\FILES01\Public Microsoft Windows Network
The command completed successfully.Значення: Є існуюча сесія. Якщо раніше використали неправильні облікові дані — Windows буде їх повторно використовувати і продовжувати давати помилки загадково.
Рішення: Видаліть сесію і підключіться заново з правильною ідентичністю при потребі.
Завдання 15: Очистити SMB‑підключення (обережно)
cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use \\FILES01\Public /delete'"
\\FILES01\Public was deleted successfully.Значення: Кешоване підключення видалено.
Рішення: Повторіть спробу доступу. Якщо тепер працює — ваша «проблема з виявленням» була насправді проблемою автентифікації/сесії.
Завдання 16: Перевірити функції/служби Windows, що часто ламають виявлення в «заточених» образах
cr0x@server:~$ powershell -NoProfile -Command "Get-Service LanmanServer,LanmanWorkstation,Browser | Select-Object Name,Status,StartType"
Name Status StartType
---- ------ ---------
LanmanServer Running Automatic
LanmanWorkstation Running Automatic
Browser Stopped DisabledЗначення: Сервер і Workstation служби запущені (потрібні для SMB). Стара служба Computer Browser вимкнена (нормально для сучасних Windows).
Рішення: Не намагайтесь воскресити Browser як виправлення. Вирішіть проблему резолюції імен і досяжності SMB.
Завдання 17: Переконатися, що машина слухає SMB (на цільовій стороні)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object -First 5 LocalAddress,LocalPort,State"
LocalAddress LocalPort State
------------ --------- -----
0.0.0.0 445 Listen
:: 445 ListenЗначення: SMB слухає на IPv4 і IPv6. Якщо ні — файлообмін не працюватиме незалежно від виявлення.
Рішення: Якщо не слухає — перевірте службу LanmanServer і конфігурацію сервера; переконайтесь, що файлообмін увімкнено і не блокується захистом кінцевої точки.
Завдання 18: Перевірити журнали подій на помилки публікації виявлення
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 20 | Where-Object {$_.ProviderName -match 'FDResPub|FDPHost'} | Select-Object -First 3 TimeCreated,ProviderName,Id,Message | Format-List"
TimeCreated : 2/5/2026 9:10:22 AM
ProviderName : FDResPub
Id : 7023
Message : The Function Discovery Resource Publication service terminated with the following error: Access is denied.Значення: Служба падає; «Access is denied» часто вказує на права, заточку образу або втручання продукту безпеки.
Рішення: Не переключайте настройки хаотично. Виправте відмову служби (базовий образ, GPO або політика продукту безпеки) або прийміть, що виявлення навмисно вимкнене.
Три корпоративні міні-історії з поля бою
Міні‑історія №1: Інцидент, викликаний неправильною гіпотезою
Мали невеликий офіс із файловим сервером, кількома Windows 10‑машинами і «простою» вимогою: усі бачили б сервер у Провіднику в розділі Мережа. Прийшов тикет: «Сервер зник. Певно впав.» Користувачі панікували. Керівництво питало ETA.
Сервер був цілий. SMB по IP працював одразу. Навіть SMB по імені працював з PowerShell. Тільки перегляд Мережі був порожній, і саме йому довіряли користувачі.
Неправильна гіпотеза була в тому, що перегляд Мережі — авторитетний. Ні. Це опортуністичний UI виявлення. Коли ми пояснили «підключайтесь по UNC; не дивіться в браузинг», паніка спала. Але потрібно було вирішити проблему сприйняття.
Причина: оновлення безпекового базового образу перемкнуло профіль NIC на Public після перевстановлення драйвера Wi‑Fi. Цей один перемикач мовчки вимкнув правила виявлення брандмауера. Система не «зламалась»; вона просто припинила рекламувати себе.
Ми виправили профіль через політику, забезпечили увімкнення правил виявлення лише для Domain/Private і опублікували ярлик на робочому столі до \\FILES01\Public. Аварія закінчилася в момент, коли припинили сприймати поведінку UI як стан сервісу.
Міні‑історія №2: «Оптимізація», що обернулась проти
Інше середовище вирішило «почистити мережевий шум». Хтось прочитав, що LLMNR і NetBIOS небезпечні (і це правда), і нарядив жорсткий GPO: відключити LLMNR, відключити NetBIOS over TCP/IP і суворо обмежити вхідні правила. Намір був розумний: зменшити площу атаки.
Через два тижні хелпдеск забитий повідомленнями «не бачу комп’ютер», «не можу змонтувати диск», «принтер зник». Фішка: DNS не був послідовно налаштований для робочих станцій на менших сайтах. Вони непомітно спирались на broadcast/multicast резолюцію імен.
Отже «оптимізація» прибрала механізми резервного копіювання, не надавши заміни. Мережа не стала безпечнішою — вона стала хаотичною. Користувачі почали ділитись IP‑адресами в чатах, ніби це колекційні картки.
Виправлення не в «ввімкнути все назад». Виправлення — завершити роботу: зробити DNS надійним (включно з динамічними оновленнями, де треба), забезпечити клієнтів правильними DNS через DHCP і документувати підтримуваний спосіб підключення (імена, а не браузинг). Тоді можна залишити LLMNR вимкненим і мати передбачуваний досвід.
Покращення безпеки, що ламають базові операції, не приживаються — їх потай обходять. Побудуйте злітно‑посадкову смугу, перш ніж просити пілотів приземлятись.
Міні‑історія №3: Нудна правильна практика, що врятувала день
У фінансовому відділі був «файлик на робочому столі» (так, ще є), який ми мігрували на сервер. Ми знали, що виявлення буде крихким: сегментований Wi‑Fi, кілька VLAN і роутер, що ставиться до мультикасту, як до особистої образи.
Тому ми не прагнули до браузингу взагалі. Зробили три нудні речі: стабільні DNS‑записи, один UNC‑шлях, що ніколи не змінюється, і мапінг дисків через політику. Також явно налаштували групи правил Windows Firewall для Domain/Private замість «як воно вийде».
Через місяці хтось замінив роутер. Виявлення стало дивним на кількох підмережах. Перегляд «Мережа» знову став будинком з привидами. Але ніхто не помітив, бо операційний шлях — маповані диски і прямий UNC — продовжував працювати. Квитків не було. Міграція виглядала «магічно гладкою».
Це не магія. Це вибір детермінованих систем замість відчуттів. Browsing — це відчуття.
Типові помилки: симптом → корінна причина → виправлення
Саме тут більшість часу спалюється. Не робіть так.
1) Симптом: Папка «Мережа» порожня, але інтернет працює
Корінна причина: Мережевий профіль — Public, або групи правил виявлення вимкнені для активного профілю.
Виправлення: Встановіть мережу як Private (якщо довірена). Увімкніть групу правил «Мережеве виявлення» для Private. Переконайтесь, що FDResPub працює.
2) Симптом: Можу доступитися до \\IP\Share, але не до \\HOST\Share
Корінна причина: Збої резолюції імен (DNS відсутній/неправильний; LLMNR/NetBIOS вимкнені; мультикаст заблокований).
Виправлення: Зробіть DNS авторитетним (переважно). Для тимчасової діагностики додайте запис у hosts або використовуйте IP, поки виправляєте DHCP/DNS.
3) Симптом: Ping працює, але SMB не працює (порт 445 закритий)
Корінна причина: Брандмауер на цілі блокує вхідний SMB, або мережа сегментована (ізоляція гостьового Wi‑Fi, ACL на VLAN).
Виправлення: Увімкніть правила «Файли та принтери» для Private/Domain. Виправте мережеву ізоляцію. Не намагайтесь «вирішити виявлення», коли SMB заблоковано.
4) Симптом: Один ПК бачить інших, але інші його не бачать
Корінна причина: «Невидимий» ПК не публікується (FDResPub зупинено/вимкнено), або його брандмауер блокує вхідний трафік виявлення.
Виправлення: Запустіть/увімкніть FDResPub. Увімкніть правила «Мережеве виявлення» на публікуючому ПК для Private/Domain.
5) Симптом: Працювало до оновлення Windows або поновлення образу
Корінна причина: Служби скинуті на Manual/Disabled, правила брандмауера змінені, профіль NIC помінявся, або застосовано базовий політик безпеки.
Виправлення: Забезпечте бажаний стан через GPO/Intune. Не спирайтесь на локальні правки, які оновлення можуть скасувати.
6) Симптом: У доменному середовищі виявлення нестабільне між підмережами
Корінна причина: Протоколи виявлення часто залежать від broadcast/multicast і не проходять через маршрутизатори стабільно.
Виправлення: Використовуйте DNS + прямі UNC‑шляхи. Якщо потрібна схожа на каталог поведінка, використовуйте AD, DFS‑простори імен або керований інвентар — не браузинг.
7) Симптом: «У вас немає дозволу» або постійні підказки облікових даних
Корінна причина: Несумісні облікові дані, кешовані сесії, обмеження NTLM або невідповідність дозволів на шар/NTFS ACL.
Виправлення: Очистіть існуючі сесії net use і підключіться заново; перевірте дозволи на шар і NTFS ACL; узгодьте політику автентифікації з реальністю.
8) Симптом: Новий Windows 11 ПК не може доступитися до старого NAS
Корінна причина: NAS потребує SMB1 або слабкої автентифікації; сучасний Windows блокує це за замовчуванням.
Виправлення: Оновіть прошивку/налаштування NAS на SMB2/3. Якщо доводиться вмикати SMB1 — ізолюйте пристрій/мережу і явно прийміть ризик.
Жарт #2: Увімкнути SMB1 у 2026‑му, щоб «полагодити виявлення» — як полагодити тече кран, встановивши пожежний шланг.
Чеклісти / покроковий план (зробіть так, щоб працювало стабільно)
Чекліст A: Дім або малий офіс (workgroup), де ви дійсно хочете браузинг
- Розмістіть пристрої в одній LAN (не гостьовий Wi‑Fi, не ізольовані SSID). Якщо роутер має «AP isolation» або «client isolation» — вимкніть для довіреної мережі.
- Встановіть мережевий профіль на Private на кожному Windows ПК, що має шаритися/виявлятися.
- Увімкніть Мережеве виявлення + Файли та принтери (групи правил брандмауера) для профілю Private.
- Переконайтесь, що FDResPub і FDPHost працюють (Automatic підходить для домашньої LAN).
- Підтвердіть, що SMB працює напряму: доступ до
\\HOST\Shareі\\IP\Share. - Виправте резолюцію імен:
- Найкраще: ваш роутер надає DNS‑записи (деякі так роблять), або у вас є невеликий DNS‑сервер.
- Прийнятно: записи у hosts для кількох машин.
- Уникайте: покладатись на «те, що Windows сьогодні знайде».
- Зробіть доступ зручним: створіть ярлики або змонтуйте диски; навчіть користувачів користуватись ними замість браузингу.
Чекліст B: Корпоративна LAN (домен), де надійність важливіша за іконки
- Визначте підтримуваний UX: прямі UNC‑шляхи, маповані диски, DFS‑простори імен або SharePoint/OneDrive. Виберіть одне і стандартизуйте.
- Зробіть DNS правильним і повним: клієнти повинні використовувати корпоративний DNS (через DHCP), а сервери мати стабільні імена.
- Застосуйте політику брандмауера:
- Увімкніть вхідні правила «Файли та принтери» тільки для Domain профілю (іноді Private для керованого Wi‑Fi).
- Тримайте їх вимкненими для Public, завжди.
- Явно встановіть необхідні служби через GPO/Intune. Не покладайтесь на дефолти, які змінюють образи і оновлення.
- Не покладайтесь на broadcast/multicast виявлення між підмережами. Це крихке і часто блокується справедливо.
- Моніторьте досяжність SMB (порт 445) і помилки автентифікації. Це ваше справжнє здоров’я сервісу, а не Провідник.
Чекліст C: Коли потрібно довести, де помилка (імена vs порти vs автентифікація)
- За ім’ям:
Resolve-DnsName, потімTest-NetConnection -Port 445. - За IP:
Test-NetConnection IP -Port 445. - Через перерахунок SMB:
net view \\HOST. - Через прямий шлях: відкрийте
\\HOST\Share. - Якщо автентифікація падає: перевірте сесії
net use; очистіть і підключіться заново; валідуйте ACLи.
FAQ
1) Чому я можу пінгувати ПК, але не бачу його в Мережі?
Ping — це ICMP. Виявлення — це суміш мультикасту/broadcast і публікації служб. Windows може блокувати виявлення, при цьому дозволяти ping (або навпаки). Розглядайте їх як окремі тести.
2) Якщо папка «Мережа» порожня, чи означає це, що файлообмін зламаний?
Ні. Папка «Мережа» не є джерелом істини. Перевірте SMB напряму з \\HOST\Share або Test-NetConnection -Port 445.
3) Які служби справді потрібні для виявлення Windows?
Поширені: FDResPub і FDPHost. SSDP/UPnP можуть грати роль для деяких сценаріїв, але вмикати їх скрізь не завжди найкраще.
4) Чи варто вмикати SMB1, щоб це виправити?
Майже ніколи. SMB1 — спадковий протокол з великою історією проблем безпеки. Якщо пристрій його вимагає, ізолюйте ту одиницю/мережу і плануйте заміну.
5) Чому \\192.168.x.x\share працює, а \\hostname\share — ні?
Бо резолюція імен провалюється. Виправіть DNS (краще), або тимчасово використовуйте hosts. Вимикання LLMNR/NetBIOS без готового DNS — класична самосаботажна помилка.
6) Чому деякі ПК з’являються і зникають випадково?
Виявлення залежить від періодичних анонсів і протоколів, що не завжди переживають сплячку, роумінг Wi‑Fi, VPN‑клієнти, скидання драйверів або фільтрацію мультикасту. Для стабільності використовуйте маповані диски і доступ через DNS.
7) Я на гостьовому Wi‑Fi. Чи можна заставити виявлення працювати?
Зазвичай ні, і це навмисно. Гостьові мережі часто ізолюють клієнтів один від одного. Якщо потрібен доступ — використовуйте довірений SSID/VLAN або VPN до мережі, де підтримуються DNS і SMB.
8) Як зрозуміти, що проблема в брандмауері Windows?
Перевірте, чи доступний порт 445 (Test-NetConnection -Port 445) і чи увімкнені групи правил брандмауера для «Мережеве виявлення» та «Файли та принтери» для активного профілю.
9) Чому це працює по Ethernet, а не по Wi‑Fi?
Різні профілі (Private vs Public), різна політика брандмауера або ізоляція клієнтів/фільтрація мультикасту на точці доступу. Також деякі продукти безпеки застосовують суворіші політики для Wi‑Fi.
10) Яке «краще» рішення в бізнес‑середовищі?
Перестаньте покладатись на браузинг. Використовуйте DNS + прямі UNC‑шляхи, маповані диски через політику і явну конфігурацію брандмауера/служб. Робіть усе детерміновано.
Наступні кроки (утримайте працездатність)
Якщо ви хочете, щоб це залишалось виправленим, робіть операційні речі, а не сподівання:
- Стандартизуйтe шляхи доступу (UNC, маповані диски або DFS), щоб користувачі не залежали від перегляду Мережі.
- Зробіть DNS надійним. Якщо імена важливі — DNS має бути правильним, крапка.
- Застосуйте політику (GPO/Intune) для:
- Очікування мережевого профілю (де можливо)
- Груп правил брандмауера для Domain/Private
- Старту служб FDResPub/FDPHost
- Тестуйте те, що важливо: досяжність порту 445 і реальний доступ до шарів. Провідник — приємність, а не критичний компонент.
- Будьте явними щодо позиції безпеки: виявлення і шаринг тільки в довірених мережах; всюди інде — заблоковано.
Перемога — не в тому, щоб зробити папку «Мережа» гарною. Перемога — зробити доступ до файлів передбачуваним — сьогодні, після наступного оновлення Windows і під час заміни роутера, коли всі клянуться, що «нічого не змінювали».