Как известно, в Windows Firewall существует три предопределённых профиля – Domain, Private и Public, к которым могут быть отнесены те или иные правила брандмауэра. Механизм автоматического выбора какого-либо из этих профилей в качестве активного текущего профиля системы для меня всегда был чем-то непознанным и магическим. Поэтому при настройке разрешающих правил брандмауэра я в большинстве случаев стараюсь придерживаться принципа привязки правила сразу ко всем трём профилям. То есть, чтобы правило работало вне зависимости от того, какой из профилей выберет себе система на тот или иной момент времени. И, вроде бы, можно жить и не обращать внимания на то, какой профиль в данный момент активен. Однако, иногда проблемы с неправильным определением профиля в Windows Firewall могут создавать дополнительные мелкие неприятности.
Рассмотрим на примере частного случая ситуацию, которая на самом деле на моей памяти воспроизводилась плавающим образом несколько раз на разных серверах с Windows Server 2012 R2.
Ко мне обратился коллега с просьбой помочь разобраться с навязчивыми алертами, периодически прилетающими с системы мониторинга SCOM о якобы неправильной настройке правил брандмауэра на файловом сервере:
Alert: Server Service: File and Printer Sharing Ports Blocked
Source: FS01 (SMB)
Path: FS01.holding.com
Description: Either Windows Firewall is disabled or the firewall inbound rules for TCP ports 445 or 139 are disabled.
Проблема заключалась в том, что на самом деле стандартное системное правило "File and Printer Sharing (SMB-In)", разрешающее входящие подключения SMB, было активно, настроено и включено для всех трёх профилей Windows Firewall.
Анализ скрипта, зашитого в соответствующее правило мониторинга в SCOM показал, что успешным считается результат проверки только при условии, что текущим активным профилем Windows Firewall является либо Domain, либо Private. Однако при этом на самом файловом сервере в качестве текущего профиля устанавливался профиль Public, хотя сервер присоединён к домену Active Directory и не имеет явных проблем с аутентификацией в этом домене.
После некоторых экспериментов, стало понятно, что ручной перезапуск службы "Network Location Awareness" на системе, которая загрузилась с неправильным определением профиля, приводит к переоценке ситуации и профиль успешно меняется на доменный.
Get-Service -Name 'NLASvc' | Restart-Service -Force
Get-NetConnectionProfile
Однако после очередной перезагрузки системы, могло получиться так, что профиль снова не определялся как доменный.
Возникло предположение о том, что служба "Network Location Awareness" при старте системы пытается выполнять свои начальные проверки ещё до момента, когда сеть полностью инициализирована.
Поэтому в качестве обходного решения для данной проблемы был изменён тип запуска службы с "Automatic" на "Automatic (Delayed Start)".
По нашим наблюдениям, после изменения типа запуска службы, проблема повторно не воспроизводилась.
RSS - Записи
Добавить комментарий