«Невідома мережа»: виправити NLA без гри з реєстром

February 24, 2026 • February 24, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ви заходите на сервер Windows, який мав би бути в доменному профілі. Натомість він показує «Невідома мережа», брандмауер переходить у профіль Публічний (Public), і раптом ваш агент моніторингу не може зв’язатися з центром, завдання резервного копіювання тайм-аутиться, а до Remote Desktop можна підключитися лише з «того одного jump host».

Саме тут люди починають займатися астрологією реєстру. Не робіть так. «Невідома мережа» — це не характерна риса системи; це збій у конвеєрі виявлення. Виправте конвеєр: вхідні дані NLA, реальність DNS, поведінку DHCP і сервіси, які це все склеюють.

Що насправді означає «Невідома мережа» (і чого це не означає)

Windows не ставить «Невідома мережа» на інтерфейс тому, що він такий містичний. Воно позначається, коли служба Network Location Awareness (NLA, ім’я служби NlaSvc) не може з упевненістю зіставити цей інтерфейс з відомою мережею. Текст у UI нечіткий; поведінка під ним — ні.

Є дві різні проблеми, які люди плутають:

Мережа невідома: NLA не може класифікувати мережу, тому Windows присвоює категорію «Невідома». Це зазвичай переводить брандмауер у профіль Публічний (Public) — більш обмежувальний.
Мережа ідентифікована, але неправильно профільована: NLA ідентифікувала мережу, але вона опинилася в Приватному (Private) або Публічному замість Доменного (Domain). Це інший режим збою — часто помилка в DNS/DC locator, а не «невідома мережа».

«Невідома» не означає «немає IP-з’єднання». Ви можете мати коректну IP-адресу, пінгувати шлюз, навіть переглядати інтернет — і все одно бути «невідомою». NLA дбає про сигнали ідентичності (DNS-суфікс, контролери домену, підказки 802.1X, характеристики шлюзу за замовчуванням), а не тільки про те, чи йдуть пакети.

Ще одне розмежування, яке заощадить години: класифікація NLA відбувається на рівні інтерфейсу. Сервер з кількома NIC (або VPN-адаптером) може мати один інтерфейс у профілі Domain, а інший — як Невідомий — і Windows прийме рішення про брандмауер/профілі, які вас здивують. Мультіхомінг перетворює «просто» на «я це ненавиджу».

Як NLA приймає рішення: сигнали та логіка

NLA — це класифікатор. Він спостерігає набір сигналів, потім обирає категорію і профіль. Ви не виправите його, примусово призначивши відповідь; ви виправите його, зробивши сигнали послідовними і доступними вчасно.

Основні сигнали, на які спирається NLA

Дані, що надає DHCP: не лише IP-адреса, а й опції, як-от DNS-сервери і доменний/пошуковий суфікс (часто опція 15). Статичні конфіги можуть працювати; неохайні статичні конфіги зазвичай — ні.
Налаштування DNS-клієнта: DNS-сервери та списки суфіксів, прив’язані до інтерфейсу. Якщо DNS вказує на «публічні резолвери» на машині, приєднаній до домену, чекайте дивної поведінки профілю.
Доступність контролера домену: для доменного профілю Windows хоче знайти DC і валідувати його. Це зазвичай через SRV-записи і логіку DC locator. Якщо DNS неправильний або заблокований, виявлення профілю Domain зазвичай не вдається.
Шлюз за замовчуванням і таблиця маршрутів: NLA очікує розумної маршрутизації. Дивний порядок метрик, кілька маршрутів за замовчуванням або портали із затримкою можуть збити його.
Мережевий підпис: Windows створює і кешує «підпис» мережі (подумайте про відбиток шлюзу MAC, SSID тощо). Коли це раптово змінюється, NLA може вважати мережу новою/невідомою.
Служби та таймінги: NLA залежить від інших служб. Якщо ці служби вимкнені, затримані або пошкоджені, NLA не зможе виконати свою роботу під час завантаження і може перейти в «Невідома» до тих пір (або назавжди).

Чому правки в реєстрі такі привабливі — і такі дорогі

Інтернет повний порад типу «змініть Category на 1» у якомусь ключі профілю мережі. Це не діагностика; це переписування мітки UI, залишаючи незайманою кореневу причину. Це також підставляє вас пізніше, коли мережа зміниться, кеш профілів розростеться або Group Policy очікуватиме доменного профілю, який ніколи не настане.

Робіть нудне виправлення: відновіть коректну поведінку DNS/DC locator, переконайтеся, що залежності здорові, і очищуйте застарілі підписи лише коли довели, що вони саме винні.

Одна парафразована думка від важковаговика надійності тут підходить. Werner Vogels (парафраз): Все ламається; проєктуйте й експлуатуйте системи, виходячи з цього, і відновлюйте їх швидко, коли це станеться.

Швидкий план діагностики

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

Спочатку: підтвердіть, що Windows вважає профіль

Чи інтерфейс позначений як «Невідома мережа»? Або він «Ідентифікований», але застряг у Публічному/Приватному?
Відбувається це на одному NIC, VPN-адаптері чи на всіх інтерфейсах?

По-друге: перевірте коректність IP і маршрутизації

IP-адреса, підмережа, шлюз за замовчуванням та DNS-сервери правильні?
Чи є саме один маршрут за замовчуванням там, де ви його очікуєте?

По-третє: перевірте DNS і пошук контролера домену

Чи може машина вирішити AD-домен і SRV-записи DC через налаштовані DNS-сервери?
Чи може вона досягти DC на потрібних портах (DNS, LDAP, Kerberos тощо)?

По-четверте: перевірте, що NLA та залежності запущені і не зламані політикою

Чи запущено NlaSvc?
Чи здорові Dnscache, Dhcp, Netlogon?
Чи щось не встановлено в стан Disabled «для жорсткого захисту» без розуміння масштабів впливу?

По-п’яте: лише потім розгляньте застарілі мережеві підписи

Чи змінився шлюз, NIC, VM або чи перебудовувався hypervisor vSwitch?
Якщо так — очищуйте застарілі профілі/підписи контрольовано (не випадковими правками реєстру).

Жарт №1: Якщо ви «виправили» NLA, видаливши випадкові ключі реєстру, ви не вирішили проблему — ви прийняли нову.

Практичні кроки: команди, виводи та рішення (12+)

Ці кроки впорядковані так, щоб ви могли зупинитися, коли знайдете джерело проблеми. Команди показані в стилі Linux-підказки, тому що це стаття, а не UX-дисертація; запускайте Windows-команди в PowerShell або CMD за потреби.

Завдання 1: Побачити поточний мережевий профіль по інтерфейсу

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -AutoSize"
Name             InterfaceAlias  InterfaceIndex NetworkCategory IPv4Connectivity IPv6Connectivity
----             --------------  -------------- --------------- ---------------- ----------------
Network          Ethernet0       12             Public          Internet         NoTraffic
Unidentified net vEthernet (NIC) 25             Public          LocalNetwork     NoTraffic

Що це означає: NLA класифікував обидва інтерфейси як Публічні (Public). Один із них фактично «Невідомий». Зауважте псевдонім інтерфейсу і його індекс.

Рішення: Зосередьтеся на інтерфейсі, який має бути Domain (зазвичай основний NIC). Якщо vEthernet або VPN-адаптер позначений як «Невідомий», він все одно може вплинути на поведінку брандмауера залежно від порядку прив’язки — не ігноруйте це.

Завдання 2: Перевірити, чи Windows вважає машину приєднаною до домену і до якого

cr0x@server:~$ powershell -NoProfile -Command "(Get-CimInstance Win32_ComputerSystem) | Select-Object PartOfDomain, Domain"
PartOfDomain Domain
------------ ------
True         corp.example.com

Що це означає: Приєднання до домену — так. Добре. Якщо False, доменний профіль ніколи не з’явиться.

Рішення: Якщо машина не приєднана до домену, перестаньте ганятися за NLA. Спочатку виправте приєднання/довіру.

Завдання 3: Перевірити IP, шлюз і DNS на ураженому інтерфейсі

cr0x@server:~$ ipconfig /all
Windows IP Configuration

Ethernet adapter Ethernet0:
   Connection-specific DNS Suffix  . : corp.example.com
   Description . . . . . . . . . . . : Intel(R) Ethernet
   Physical Address. . . . . . . . . : 00-15-5D-01-02-03
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.20.30.40(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.20.30.1
   DNS Servers . . . . . . . . . . . : 8.8.8.8
                                       1.1.1.1

Що це означає: Суфікс виглядає як доменний, але DNS-сервери — публічні резолвери. Це ламає виявлення DC і може спричинити перехід у профіль Публічний (Public).

Рішення: Змініть DNS-сервери на інтегровані з AD (зазвичай DC) або на внутрішні резолвери, які відповідають на SRV-запити AD.

Завдання 4: Підтвердити, що таблиця маршрутів не кошмар

cr0x@server:~$ route print
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.20.30.1     10.20.30.40     25
          0.0.0.0          0.0.0.0      10.99.0.1      10.99.0.20      5
===========================================================================

Що це означає: Два маршрути за замовчуванням. Менша метрика перемагає (метрика 5), тож трафік виходить через 10.99.0.1. Якщо ця мережа не може дістатися до DC/DNS, NLA може не пройти класифікацію.

Рішення: Видаліть небажаний шлюз за замовчуванням, відкоригуйте метрики інтерфейсів або додайте специфічні маршрути, щоб трафік до домену/DC йшов правильним шляхом.

Завдання 5: Перевірити стан служби NLA

cr0x@server:~$ powershell -NoProfile -Command "Get-Service NlaSvc | Format-List Status,StartType,Name,DisplayName"
Status    : Running
StartType : Automatic
Name      : NlaSvc
DisplayName : Network Location Awareness

Що це означає: Служба працює. Якщо вона зупинена/відключена, ви знайшли винуватця.

Рішення: Якщо Disabled — увімкніть. Якщо не стартує — перевірте залежності і журнали подій перед тим, як перезапускати все підряд.

Завдання 6: Перевірити ключові служби-залежності (DNS client, DHCP, Netlogon)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache,Dhcp,Netlogon | Format-Table -AutoSize Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
Dnscache Running Automatic
Dhcp     Running Automatic
Netlogon Running Automatic

Що це означає: Якщо Dnscache відключено, отримаєте дивну поведінку DNS. Якщо Dhcp відключено, але ви покладаєтесь на DHCP — очікуйте часткову конфігурацію. Якщо Netlogon зламався, виявлення доменного профілю часто не працює.

Рішення: Відновіть розумні типи запуску (зазвичай Automatic). Якщо політика жорсткого захисту відключила їх — відкотіть або виправте політику належним чином.

Завдання 7: Перевірити, чи DNS може вирішити AD-домен і SRV-записи контролерів

cr0x@server:~$ nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com
Server:  one.one.one.one
Address: 1.1.1.1

*** one.one.one.one can't find _ldap._tcp.dc._msdcs.corp.example.com: NXDOMAIN

Що це означає: Ви запитуєте не той DNS-сервер. Публічні резолвери не містять ваших внутрішніх SRV-записів AD.

Рішення: Виправте конфігурацію DNS-серверів. Потім тестуйте знову, поки SRV-записи не почнуть повертати ваші DC.

Завдання 8: Перевірити DC locator з точки зору машини

cr0x@server:~$ nltest /dsgetdc:corp.example.com
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Що це означає: Машина не може знайти DC для домену (звичайно через неправильний DNS, маршрутизацію або заблоковані порти).

Рішення: Спочатку виправте DNS і маршрути. Якщо DNS вірний — перевірте правила брандмауера між цим хостом і DC.

Завдання 9: Перевірити стан профілів Windows Firewall

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Format-Table -AutoSize Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Що це означає: Всі профілі ввімкнені; це нормально. Більшість проблем — у тому, який профіль активний на NIC.

Рішення: Не «виправляйте» це відключенням брандмауера. Виправте виявлення профілю, щоб застосовувалися правильні правила.

Завдання 10: Підтвердити, який профіль брандмауера застосовано до кожного інтерфейсу

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 6 InterfaceAlias,AddressFamily,InterfaceMetric,ConnectionState | Format-Table -AutoSize"
InterfaceAlias      AddressFamily InterfaceMetric ConnectionState
--------------      ------------- -------------- ---------------
Ethernet0           IPv4          25             Connected
vEthernet (NIC)     IPv4          5              Connected

Що це означає: Інтерфейс vEthernet має меншу метрику і може бути пріоритетним для вихідного трафіку, включно з DNS-запитами.

Рішення: Якщо керуючий vSwitch/vNIC «краде» пріоритет шлюзу за замовчуванням, виправте метрики або приберіть його шлюз.

Завдання 11: Переглянути журнали подій на помилки класифікації NLA

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-NlaSvc/Operational' -MaxEvents 12 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated : 2/5/2026 9:12:11 AM
Id          : 4002
LevelDisplayName : Warning
Message     : NLA failed to retrieve the domain authentication status. Error: 0x54b

Що це означає: NLA не може визначити статус доменної автентифікації. Часто це пов’язано з Netlogon/виявленням DC або DNS.

Рішення: Розглядайте це як симптом; вирішіть зовнішню причину (DNS/досяжність DC), а не лог сам по собі.

Завдання 12: Примусова реєстрація DNS і оновлення місцезнаходження мережі (безпечні підштовхування)

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

cr0x@server:~$ ipconfig /registerdns
Windows IP Configuration
Registration of the DNS resource records for all adapters of this computer has been initiated.

Що це означає: Ви очистили кеш резолвера і ініціювали динамічну реєстрацію DNS.

Рішення: Застосовуйте це після виправлення DNS-серверів/суфіксів. Це не виправить зламану маршрутизацію чи неправильні резолвери, але допомагає після виправлення вхідних даних.

Завдання 13: Оновити DHCP-оренду (коли використовується DHCP)

cr0x@server:~$ ipconfig /renew
Windows IP Configuration
Renewing Ethernet adapter Ethernet0...
Ethernet adapter Ethernet0 has been renewed.

Що це означає: Якщо DHCP видавав неправильні DNS/суфікс, це отримає оновлені опції.

Рішення: Якщо при оновленні знову повертаються публічні DNS або пустий суфікс, виправляйте опції scope DHCP або бронювання.

Завдання 14: Перевірити, чи проксі/VPN-адаптер не отруює DNS

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress | Format-Table -AutoSize InterfaceAlias,AddressFamily,ServerAddresses"
InterfaceAlias        AddressFamily ServerAddresses
--------------        ------------- --------------
Ethernet0             IPv4          {10.20.30.10, 10.20.30.11}
CorpVPN               IPv4          {172.16.1.53}

Що це означає: VPN-інтерфейс має власний DNS-сервер. Якщо маршрутизація віддає перевагу VPN, виявлення DC може піти не туди, куди потрібно.

Рішення: Виправте split DNS/split-tunnel, відкоригуйте метрики або переконайтеся, що DNS у VPN може вирішувати внутрішні AD-запити коректно.

Завдання 15: Перевірити базову досяжність DNS і портів DC

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.30.10 -Port 53"
ComputerName     : 10.20.30.10
RemoteAddress    : 10.20.30.10
RemotePort       : 53
InterfaceAlias   : Ethernet0
TcpTestSucceeded : True

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection dc01.corp.example.com -Port 389"
ComputerName     : dc01.corp.example.com
RemoteAddress    : 10.20.30.10
RemotePort       : 389
InterfaceAlias   : Ethernet0
TcpTestSucceeded : True

Що це означає: DNS доступний; LDAP доступний. Якщо це не так, NLA, ймовірно, не зможе довести «Доменну мережу».

Рішення: Якщо порт блокується — виправте мережеві ACL, правила хост-брандмауера або неправильні маршрути. Не очікуйте, що NLA «чарівно» класифікує домен, якщо він недосяжний.

Завдання 16: Підтвердити профіль після виправлень

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -AutoSize InterfaceAlias,Name,NetworkCategory"
InterfaceAlias      Name     NetworkCategory
--------------      ----     ---------------
Ethernet0           Network  DomainAuthenticated
vEthernet (NIC)     Network  Public

Що це означає: Основний інтерфейс тепер DomainAuthenticated. Вторинний залишається Публічним, що може бути прийнятно, якщо це приватний vSwitch або ізольований лінк.

Рішення: Перевірте, чи тепер працюють потрібні сервіси (моніторинг, WinRM, SMB, резервне копіювання). Якщо так — припиніть трогати систему.

Три корпоративні історії з реального життя

1) Інцидент через хибне припущення: «Це просто мітка»

Середнє підприємство мало набір вузлів Windows Server за балансувальником навантаження. Планове оновлення. Один вузол повернувся з «Невідомою мережею». Інженер на чергуванні знизав плечима — перевірка здоров’я через балансувальник показувала трафік, додаток відповідав локально.

До ранку помилки клієнтів різко зросли. Не катастрофа, але неприємний дощ з відмов. Вузол міг приймати вхідний трафік, але не діставався до сервісу ліцензування і кількох внутрішніх API. Профіль брандмауера був Публічним, а вихідні правила для внутрішніх адрес були обмежені для Доменного профілю.

Хибне припущення полягало в тому, що «Невідома мережа» — косметична проблема. Ні. Вона змінила політику брандмауера й непомітно обмежила вихід. Моніторинг цього не помічав, бо вузол все ще відповідав на базові TCP-перевірки; бізнес-логіка ламалася пізніше.

Вони «виправили» це примусово, встановивши профіль Приватний через правку реєстру. Працювало до наступного перезавантаження, потім поверталося. Тоді вже перевірили DNS: DNS-сервери вузла задавалися скриптом провізії як публічні резолвери «тимчасово». Тимчасове тривало місяцями, як це часто буває.

Коли DNS вказали на AD DNS і DC locator запрацював, вузол стабільно став DomainAuthenticated. Жодних правок реєстру. Додатково вони додали перевірку на етапі завантаження в конфіг-менеджмент, яка фейлить білд, якщо основний інтерфейс не став DomainAuthenticated протягом граціозного періоду.

2) Оптимізація, яка обернулася проти: «Вимкнемо служби, щоб швидше завантажуватися»

Фінансова організація посилювала базові налаштування. Хтось придумав ідею: відключити «необов’язкові» служби, щоб скоротити час завантаження і зменшити поверхню атаки. У списку були DHCP Client на серверах, бо «сервери статичні». Також вимкнули Network Location Awareness, бо «нам не потрібен той UI».

Більшість серверів спочатку цього не помітила. Статичні IP працювали; життя йшло далі. Потім кластер Hyper-V почав повідомляти про періодичні збої: гостьові VM іноді запускалися з неправильним профілем брандмауера, агенти управління не могли підключитися, а скрипти live migration падали з помилками, схожими на проблеми Kerberos.

Корінь проблеми — у таймінгах. NLA не працював, а DHCP Client був відключений, хоча деякі інтерфейси все ще чекали DHCP (особливо віртуальні адаптери, створені інструментами). Додатково Netlogon стартував із затримкою, бо машина не могла надійно класифікувати і пріоритезувати мережеві зв’язки під час завантаження.

«Оптимізація» зекономила кілька секунд під час завантаження і коштувала годин операційного болю та періодичних відмов, які важко було корелювати. Виправлення було нудним: відновити стандартні типи запуску для критичних мережевих служб, а потім захищати систему за допомогою правил брандмауера і сегментації, а не виривати трубопровід.

Вони залишили одну ідею з початкового задуму: задокументували, які служби реально безпечні для відключення в їхньому середовищі. NLA і DHCP Client у цей список не потрапили.

3) Сумна, але правильна практика, що врятувала день: «Доведіть DNS, перш ніж щось чіпати»

Глобальна компанія працювала в гібридному середовищі: on-prem AD, хмарні робочі навантаження, кілька VPN-рішень. «Невідома мережа» з’явилася на наборі Windows Server VM після зміни мережі. Helpdesk ескалував це як проблему брандмауера, бо профіль був Публічний.

SRE на чергуванні не почав з політик. Він почав із доказів: Get-NetConnectionProfile, ipconfig /all, потім nslookup -type=SRV для SRV-записів AD. Це відразу впало. DNS-сервери були вірні, але SRV-запит таймаутив. Це звузило проблему до досяжності, а не конфігурації.

Далі вони запустили Test-NetConnection до DNS і DC на портах 53/389/88. Порт 53 до DNS з підмережі був заблокований через новий ACL, призначений обмежити «серверний шум». Ніхто не додав у change request, що «DNS — це не шум».

Вони відкотили ACL, потім знову застосували його з явними дозволами для DNS. NLA миттєво повернувся до DomainAuthenticated без перезавантаження. Жодних правок реєстру, жодних перезапусків служб, жодного «вмикни-вимкни». Просто методичне доведення, що машина не могла дістатися джерела ідентичності, яке вона використовує для рішення профілю.

Та практика — довести DNS і досяжність перед тим, як щось крутити — здається нудною. Нудне — добре. Нудне зберігає вихідні дні від роботи.

Поширені помилки: симптом → корінь → виправлення

1) «Невідома мережа» після перезавантаження на сервері, приєднаному до домену

Симптом: Основний NIC стає Невідомим; брандмауер переходить у Публічний (Public); RDP/WinRM/SMB перестають працювати за старими правилами.

Корінь: DNS-сервери не вказують на AD DNS або DC недоступні під час завантаження через маршрути/ACL. NLA не може підтвердити статус доменної автентифікації.

Виправлення: Виправте список DNS-серверів і суфікс; перевірте SRV-запити і nltest /dsgetdc. Потім переконайтеся, що порти до DC доступні.

2) Доменний профіль ніколи не з’являється, але мережа «ідентифікована» (Приватна/Публічна)

Симптом: Мережа має дружню назву, не «Невідома», але застрягла у Приватному профілі.

Корінь: Машина приєднана до домену, але не може знайти DC з цього інтерфейсу, часто тому що пріоритетний маршрут/DNS йде через вторинний адаптер (VPN, vEthernet, резервний NIC).

Виправлення: Приберіть зайві шлюзи за замовчуванням; відкоригуйте метрики інтерфейсів; переконайтеся, що виявлення DC використовує потрібний NIC і DNS.

3) Лише гості Hyper-V показують «Невідома» на певних vSwitch

Симптом: VM на конкретному віртуальному свитчі завантажуються з Невідомою мережею; інші — нормальні.

Корінь: Цей vSwitch не має DHCP і VM очікує DHCP, або vSwitch не має шляху до DNS/DC. Іноді політики MAC-спуфінгу/безпеки створюють дивності.

Виправлення: Переконайтеся, що uplink vSwitch має правильний VLAN/теги; перевірте relay DHCP; забезпечте доступність DNS з цього сегменту.

4) «Невідома» з’являється після клонування або розгортання шаблону

Симптом: Ново розгорнутий сервер показує Невідому, поки хтось не переключить NIC вручну або не перезавантажить.

Корінь: Шаблон має застарілі мережеві підписи і/або є гонка під час першого завантаження (драйвери, служби, GPO). Реєстрація DNS також може відставати.

Виправлення: Виправте шаблон: оновіть драйвери NIC, не вмикайте публічні DNS, переконайтеся, що критичні служби увімкнено, і додайте пост-провізійну перевірку, яка чекає DomainAuthenticated перед тим, як вважати розгортання успішним.

5) Користувачі VPN: корпоративна мережа стає Невідомою після підключення VPN

Симптом: LAN переходить у Публічний профіль після встановлення VPN; внутрішні сервіси ламаються.

Корінь: VPN штовхає DNS-сервери і маршрути, які стають пріоритетними, але його DNS не може вирішити AD або VPN блокує порти DC.

Виправлення: Виправте дизайн split-tunnel/split-DNS. Забезпечте, щоб DNS VPN вирішував SRV AD або виключайте ці запити на внутрішні резолвери, до яких є доступ через VPN.

6) Хтось «пофіксив» це, відключивши профіль брандмауера

Симптом: Все знову працює; команда з безпеки панікує; аудит фіксує порушення.

Корінь: Лікування симптома (заблокований трафік) замість причини (неправильний профіль через вхідні дані NLA).

Виправлення: Увімкніть брандмауер назад, потім виправте класифікацію NLA, відновивши DNS/виявлення DC і маршрути. Додайте цілеспрямовані правила, якщо випадок справді особливий.

Жарт №2: Брандмауер Windows — як ремінь безпеки: набридливий лише тоді, коли ви робите щось, чого, можливо, не варто робити.

Чеклісти / покроковий план (спочатку безпечні виправлення)

Фаза 0: Визначте, як виглядає «правильно»

Який інтерфейс має бути DomainAuthenticated?
Чи цей хост повинен бути приєднаним до домену? (Інколи сервери навмисно не приєднані.)
Які DNS-сервери він має використовувати?
На якому сегменті/VLAN він знаходиться і чи може звідти дістатися до DC?

Фаза 1: Перевірте і виправте конфігурацію (поки без перезавантажень)

Запустіть Get-NetConnectionProfile і визначте уражений інтерфейс.
Запустіть ipconfig /all і підтвердіть DNS-сервери і суфікс для домену.
Запустіть route print; приберіть небажані шлюзи за замовчуванням і явні помилки метрик.
Запустіть nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain>, використовуючи налаштовані DNS-сервери (неявно). Виправляйте DNS, якщо запит провалюється.
Запустіть nltest /dsgetdc:<domain>. Якщо провал — трактуйте це як проблему DNS/маршрутизації/фаєрвола, поки не доведено протилежне.

Фаза 2: Доведіть досяжність джерел ідентичності

Test-NetConnection до DNS-серверів на порт 53.
Test-NetConnection до DC на портах 88 (Kerberos) і 389 (LDAP). (Може знадобитися також 445/464 залежно від середовища.)
Якщо заблоковано — виправте мережеві ACL або правила брандмауера хосту. Не обходьте проблему — вирішіть її цілеспрямовано.

Фаза 3: Невеликі підштовхування системи (мінімальні порушення)

ipconfig /flushdns і ipconfig /registerdns після корекції DNS.
Якщо DHCP — ipconfig /renew після виправлення опцій scope.
Перевірте Get-NetConnectionProfile. Якщо стає DomainAuthenticated — зупиніться.

Фаза 4: Перевірки на рівні служб (цільові перезапуски, а не «перезапустити все»)

Переконайтеся, що NlaSvc, Dnscache, Dhcp, Netlogon запущені і мають розумні типи старту.
Якщо служба «зависла», вивчіть журнали подій, щоб зрозуміти причину перед перезапуском.
Перезавантажуйте лише якщо потрібно перевірити порядок завантаження або якщо конфігураційні інструменти вимагають цього.

Фаза 5: Контрольоване прибирання (тільки за наявності доказів)

Якщо проблема почалася після зміни шлюзу/NIC/vSwitch і все інше вірно — очищуйте застарілі мережеві профілі за допомогою підтримуваних інструментів і політик, де можливо.
Уникайте видалення ключів реєстру як першого кроку. Якщо треба торкнутися реєстру з відомої, документованої причини — робіть це через change control і з планом відкату.

Цікаві факти та історичний контекст (те, що пояснює сьогоднішні дивності)

NLA існує з епохи XP/Server 2003 як API для додатків, щоб реагувати на зміни мережі; пізніші версії Windows тісно прив’язали його до профілів брандмауера.
Профілі брандмауера Windows (Domain/Private/Public) стали операційно важливими з Vista/Server 2008, коли брандмауер став увімкненим за замовчуванням у багатьох середовищах.
DomainAuthenticated — це не просто «Domain»; це вказує, що Windows підтвердив доменну доступність, зазвичай через DC locator і статус автентифікації, а не лише за збігом DNS-суфікса.
AD сильно залежить від SRV-записів DNS для знаходження контролерів домену і сервісів. Якщо DNS не відповідає на SRV-запити — у вас не «трохи зламаний AD», у вас зламаний AD.
Мультіхомінг завжди був складним у Windows; більше інтерфейсів означає більше маршрутів, більше списків DNS і більше шансів, що «неправильний» інтерфейс переможе при завантаженні.
Мобільність VM зробила мережеві підписи більш мінливими; live migration, перебудова vSwitch і зміни віртуальних NIC можуть змінити ідентифікатори, які Windows використовує для відбитка мережі.
Опції DHCP мають значення навіть у «статичних» середовищах; багато організацій тихо покладаються на DHCP для DNS-суфіксів, NTP або узгодженого призначення DNS-серверів.
Базові політики безпеки часто заходять надто далеко, відключаючи «невикористовувані» служби. Критичні мережеві служби рідко непотрібні; їх просто недооцінюють, поки їх не стане бракувати.
«Невідома мережа» часто — це історія про DNS, упакована у костюм брандмауера. UI підказує вам «мережа», але виправлення зазвичай лежить у назвоутворенні та виявленні DC.

FAQ

1) Чому «Невідома мережа» переводить у публічний профіль брандмауера?

Тому що Windows припускає, що невідомі мережі — ворожі. Профіль Публічний (Public) — найбезпечніший за замовчуванням. Якщо NLA не може довести, що це ваш домен або відома приватна мережа — система грає в обороні.

2) Можу я просто поставити мережу як Приватну і забути?

Можете, але це лікує симптом і може порушити правила брандмауера, які орієнтовані на домен, та очікування GPO. Виправте, чому мережа невідома — зазвичай це DNS/досяжність DC або пріоритет маршруту.

3) Яка найпоширеніша причина на серверах, приєднаних до домену?

Неправильні DNS-сервери. Публічні резолвери, «тимчасові» налаштування DNS або вторинний NIC/VPN, що виграє пріоритет DNS — усе це зламає виявлення DC і класифікацію NLA.

4) Якщо я можу пінгувати DC, чому NLA не бачить домен?

Пінг доводить доступність ICMP, а не вирішення SRV або доступність потрібних TCP/UDP портів (53/88/389 тощо). NLA покладається на сигнали вищого рівня, ніж «можу пінгнути».

5) Чи треба перезавантажувати після виправлення DNS?

Зазвичай ні. Після корекції DNS-серверів/суфіксів і маршрутів очистіть кеш DNS, оновіть DHCP за потреби і перевірте профіль. Перезавантажуйте лише якщо проблема пов’язана з порядком завантаження.

6) Чому це відбувається після переміщення VM на новий хост?

Входові дані мережевого підпису можуть змінитися (віртуальний свитч, видимість MAC шлюзу, ідентифікатори адаптера). Якщо VM опинилася в сегменті, який не має доступу до DNS/DC, класифікація відразу провалиться.

7) Як зрозуміти, це збій NLA чи просто відсутні правила брандмауера?

Перевірте Get-NetConnectionProfile. Якщо інтерфейс — Public/Unidentified, а мав би бути DomainAuthenticated, спочатку виправляйте вхідні дані NLA. Якщо профіль DomainAuthenticated, але трафік усе одно блокується — тоді вже політика брандмауера.

8) Чому деякі сервери показують DomainAuthenticated, але поводяться як Public?

Зазвичай трафік йде через інший інтерфейс, ніж ви думаєте (метрики/маршрут за замовчуванням), або правила зорієнтовані на неправильний інтерфейс/профіль. Перевірте маршрути і активні метрики інтерфейсів.

9) Чи є відключення NLA допустимим заходом жорсткого захисту?

Ні. Це ламатиме класифікацію мереж і призведе до непередбачуваної поведінки брандмауера. Жорстке захистення слід робити через визначення політик брандмауера, сегментацію мереж і контроль служб — не вимикаючи класифікатор.

10) А якщо я зовсім не в домені?

Тоді DomainAuthenticated не має значення. Ваше завдання — забезпечити, щоб інтерфейс правильно ідентифікувався і був встановлений як Приватний/Публічний згідно з вашою політикою, і щоб DNS/маршрути були коректні для цього середовища.

Висновок: наступні кроки, які можна зробити сьогодні

Припиніть грати в рулетку з реєстром. «Невідома мережа» — це діагностична проблема, замаскована під проблему UI. Ставтеся до неї як SRE: перевіряйте сигнали, доводьте залежності і змінюйте по одній змінній за раз.

Аудитуйте налаштування DNS-серверів на уражених хостах. Якщо сервер, приєднаний до домену, вказує на публічний DNS — виправте це в першу чергу.
Приберіть зайві шлюзи за замовчуванням і очистіть метрики інтерфейсів, щоб потрібний NIC перемагав.
Доведіть виявлення AD за допомогою SRV-запитів і nltest. Якщо вони не проходять — це не «таємнича мережа», це зламаний шлях ідентичності.
Перевірте досяжність до DNS і портів DC з фактично пріоритетного інтерфейсу хоста.
Закріпіть нудну практику: додайте пост-boot перевірку, яка оповіщує, якщо основний інтерфейс не став DomainAuthenticated протягом розумного часу.

Якщо ви зробите одну річ: зробіть DNS знову нудним. NLA любить нудне. Ваш графік чергувань теж.