Нужно ли правило брандмауэра приложению, которое только подключается к серверу как клиент?

Как правило, нет. По умолчанию брандмауэр Windows — «входящие блокировать, исходящие разрешать», поэтому клиентское приложение, которое только само инициирует соединения наружу, при значениях по умолчанию связывается нормально. Входящее правило нужно только стороне, которая открывает порт и ждёт соединений, то есть приложениям серверного типа. Есть два исключения. В средах высокой безопасности исходящие тоже могут быть переведены в блокировку по умолчанию — тогда нужно запросить и исходящее правило. И даже «клиентское» приложение нуждается во входящем правиле для той части, которая сама слушает порт, чтобы принимать уведомления о результате.

Нельзя ли просто нажать «Разрешить доступ» в диалоге «Важное предупреждение системы безопасности Windows» и этим ограничиться?

На этот момент хватит, но продакшен-эксплуатацию этому доверить нельзя. Если пользователь с правами администратора отменит этот диалог, создаётся блокирующее правило. Хуже: если прав администратора нет, блокирующее правило создаётся при любом нажатии. Пока созданное правило не удалено, диалог больше не появляется, и связь продолжает сбоить. В бизнес-приложениях, где на площадке машиной управляет обычный конечный пользователь, состояние «кто-то один раз отменил — и с тех пор никогда не соединяется» возникает тривиально легко. Сама Microsoft рекомендует размещать правило до первого запуска приложения именно чтобы этого избежать.

Входящее правило строить вокруг порта или вокруг программы?

Базовый подход — сочетать, а не брать одно. Правила по программе фиксируют цель полным путём exe, но если обновление меняет путь, правило теряет цель (подстановочные знаки не поддерживаются). Правила по порту делают заявку в ИТ однозначной, но пропускают и любой другой процесс, который слушает тот же порт. Для продакшен-бизнес-приложения схема минимальных прав — ось «программа + протокол + порт», профиль ограничить Domain/Private, удалённый IP — подсетью клиента. Правило только по программе — когда порт динамический.

Правило, которое зарегистрировал наш установщик, на ПК клиента, кажется, не действует. Почему?

Вероятно, брандмауэр клиента централизованно управляется через GPO или Intune, и «слияние локальных правил» (AllowLocalPolicyMerge) отключено. Когда этот параметр отключён, правило, созданное локально, в профиле есть, но не применяется — правила можно раздавать только централизованно через GPO/CSP. Полный набор действующих правил смотрите Get-NetFirewallRule -PolicyStore ActiveStore и просите ИТ раздать правило. Заявка проходит с одного раза, если сразу передаёте имя правила, направление, путь программы, протокол и порт, диапазон удалённых IP и профиль.

Можно ли временно отключить брандмауэр ради разбора?

Отключение остановкой службы (MpsSvc) абсолютно исключайте. Эта операция не поддерживается Microsoft и вызывает проблемы на стороне ОС: перестаёт работать меню «Пуск», сбоят обновления приложений Store. Если для разбора всё же нужно отключить, правильный способ — оставить службу работающей и отключить профиль через Set-NetFirewallProfile -Enabled False. И это ограничьте несколькими минутами проверки, виноват ли брандмауэр, и сразу верните. Держать отключённым — менять всю защиту ПК на проблему, которую решило бы одно добавленное правило.

Брандмауэр Windows и бизнес-приложения — входящие правила регистрируйте из установщика

1 Aug 2026 00:00 · Го Комура · Windows, Брандмауэр, Сеть, Безопасность, Бизнес-приложения, Установщик, PowerShell, Информационные системы

«На машине разработки всё работает, а после установки у клиента клиент не соединяется с сервером.» «При первом запуске вылезло какое-то предупреждение, и тот, кто был на площадке, вроде отменил.» «netstat показывает, что порт слушает, а с соседнего ПК не достучаться.» — на площадках внедрения бизнес-приложений жалобы такой формы — классика классик. И устойчиво в верхних строках причин сидит брандмауэр Windows (Windows Defender Firewall).

Неудобство в том, что на машине разработки проблема невидима. На машине разработки вы сами нажали «разрешить» при отладке в Visual Studio, или вы изначально администратор, и отгружаете, так и не заметив блокировку входящих по умолчанию. У клиента же машиной управляет обычный пользователь без прав администратора, а сеть управляется GPO. Это не «должно работать, а не работает» — реальность в том, что «машина разработки просто случайно работала».

Статья рассчитана на разработчиков бизнес-приложений, которые со своими внутренними приложениями упираются в «у клиента не соединяется», и на ИТ-сотрудников малого и среднего бизнеса, которые эти жалобы принимают. После минимума про поведение брандмауэра Windows по умолчанию и механизм профилей разбираются проектирование входящих правил, практика регистрации правил из установщика, процедура разбора и оговорки под управлением GPO/Intune — всё на первоисточниках по состоянию на август 2026.

1. Сначала вывод

По умолчанию брандмауэр Windows — «входящие блокировать, исходящие разрешать». Входящий трафик, который не является ответом на запрос, отбрасывается, пока не совпадёт с правилом.¹
Входящее правило нужно только приложениям серверного типа, которые слушают порт. Клиентское приложение, которое только само инициирует соединения, работает при значениях по умолчанию. Разбор начинайте отсюда.¹
Профилей три (Domain/Private/Public). Domain применяется автоматически при обнаружении контроллера домена; Public — значение по умолчанию для неопознанных сетей. Правила включаются и отключаются по профилю.¹
Продакшен нельзя оставлять тому диалогу «важного предупреждения». Если администратор отменит, создаётся блокирующее правило; у пользователя без прав администратора блокирующее правило создаётся при любом нажатии. Диалог не появится снова, пока созданное правило не удалено.²
Вывод: входящие правила бизнес-приложения регистрируйте из установщика. Сама Microsoft рекомендует разместить правило до первого запуска и отключить входящие уведомления.²
Правила проектируйте с минимальными правами. Ось — программа + протокол + порт, профиль ограничить Domain/Private, удалённый IP — нужной подсетью. В пути программы подстановочные знаки нельзя.²³
Разбор — в порядке Test-NetConnection → Get-NetFirewallRule → pfirewall.log. Журнал брандмауэра по умолчанию не пишется — появляется только после включения записи отброшенных пакетов.⁴⁵⁶
Сплошное отключение остановкой службы не поддерживается. Под управлением GPO/Intune может быть отключено «слияние локальных правил», и тогда локальные правила не действуют. Просите ИТ централизованно раздать правило.¹²

Карта знаний этой статьи

По умолчанию брандмауэр Windows блокирует входящие и разрешает исходящие; входящее правило нужно только бизнес-приложениям серверного типа, которые слушают порт. Если слушает приложение без правила, появляется диалог «важного предупреждения», но в зависимости от действий может впечься блокирующее правило и стать причиной сбоя связи, поэтому входящие правила как правило регистрируют из установщика. Под управлением GPO/Intune слияние локальных правил может быть отключено, и тогда локально зарегистрированное правило не применяется.

flowchart LR
    accTitle: Карта знаний брандмауэра Windows и бизнес-приложений
    accDescr: Рисунок, показывающий связи брандмауэра Windows, входящего правила, приложения, которое слушает, диалога «важного предупреждения», установщика и прав администратора, сужения правила (указание программы, ограничение удалённого IP), слияния локальных правил, сбоя «не связывается» и команд разбора
    windows_firewall["брандмауэр Windows"]
    inbound_rule["входящее правило"]
    listen_app["бизнес-приложение, которое слушает"]
    installer["установщик"]
    network_profile["сетевой профиль"]
    communication_failure["сбой «не связывается»"]
    firewall_notification["диалог «важного предупреждения»"]
    exe_path_change["смена пути исполняемого файла"]
    pfirewall_log["журнал брандмауэра (pfirewall.log)"]
    group_policy["групповая политика"]
    intune["Microsoft Intune"]
    local_policy_merge["слияние локальных правил"]
    mpssvc["служба брандмауэра (MpsSvc)"]
    port_rule["правило по порту"]
    over_permission["избыточное разрешение правила"]
    test_netconnection["Test-NetConnection"]
    get_netfirewallrule["Get-NetFirewallRule"]
    unsolicited_inbound["незапрошенный входящий обмен"]
    netsh_advfirewall["netsh advfirewall"]
    new_netfirewallrule["New-NetFirewallRule"]
    admin_rights["права администратора"]
    remote_ip_scope["ограничение удалённого IP"]
    program_rule["правило по программе"]
    mpssvc_stop["остановка службы MpsSvc"]
    firewall_disable["отключение брандмауэра"]
    named_pipe["именованный канал"]
    smb_445["SMB (TCP 445)"]
    get_netconnectionprofile["Get-NetConnectionProfile"]
    block_rule["блокирующее правило"]
    notify_disable["отключение входящих уведомлений"]
    service_rule["правило по службе"]
    profile_limit["ограничение профиля"]
    updater_reregistration["повторная регистрация правила при обновлении"]
    netstat["netstat"]
    listen_app -->|"требует"| inbound_rule
    installer -->|"рекомендуется для"| inbound_rule
    network_profile -.->|"может вызвать"| communication_failure
    firewall_notification -.->|"может вызвать"| communication_failure
    exe_path_change -.->|"может вызвать"| communication_failure
    communication_failure -->|"проверяется"| pfirewall_log
    windows_firewall -->|"настраивается"| group_policy
    windows_firewall -->|"настраивается"| intune
    inbound_rule -.->|"требует"| local_policy_merge
    mpssvc -->|"реализует"| windows_firewall
    windows_firewall -->|"использует"| network_profile
    port_rule -.->|"может вызвать"| over_permission
    exe_path_change -.->|"может вызвать"| firewall_notification
    firewall_notification -->|"настраивается"| group_policy
    communication_failure -->|"проверяется"| test_netconnection
    communication_failure -->|"проверяется"| get_netfirewallrule
    windows_firewall -->|"предотвращает"| unsolicited_inbound
    inbound_rule -->|"настраивается"| netsh_advfirewall
    inbound_rule -->|"настраивается"| new_netfirewallrule
    inbound_rule -->|"требует"| admin_rights
    remote_ip_scope -->|"снижает"| over_permission
    program_rule -->|"снижает"| over_permission
    firewall_notification -->|"не рекомендуется"| inbound_rule
    mpssvc_stop -->|"не рекомендуется"| firewall_disable
    remote_ip_scope -->|"рекомендуется для"| over_permission
    program_rule -->|"рекомендуется для"| over_permission
    named_pipe -->|"использует"| smb_445
    network_profile -->|"проверяется"| get_netconnectionprofile
    firewall_notification -.->|"может вызвать"| block_rule
    block_rule -->|"может вызвать"| communication_failure
    notify_disable -->|"предотвращает"| firewall_notification
    service_rule -->|"снижает"| over_permission
    profile_limit -->|"снижает"| over_permission
    updater_reregistration -->|"рекомендуется для"| exe_path_change
    communication_failure -->|"проверяется"| netstat

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 35, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Точно зафиксировать поведение по умолчанию — входящие блокируются, исходящие разрешаются

Сначала точно зафиксируем основание. Брандмауэр Windows — хостовый брандмауэр, включённый по умолчанию во всех редакциях, и поведение по умолчанию сводится к двум строкам.¹

Входящие (inbound): всё блокируется, если это не ответ на запрос (solicited) и не совпадает с правилом
Исходящие (outbound): всё разрешается, если не совпадает с правилом

Из этих двух строк следует самый важный разбор для бизнес-приложения: входящее правило нужно только «стороне, которая слушает».

Клиентское приложение, которое только само подключается к внутреннему веб-серверу, серверу БД или основной системе → как правило, правило не нужно. Обратные пакеты инициированного вами соединения считаются «ответом на запрос» и проходят по умолчанию.
Приложение серверного типа или служба Windows, которая открывает порт и ждёт соединений по TCP, gRPC, собственному протоколу и т. п. → входящее правило обязательно.
Отдельно: схема с удалёнными именованными каналами. Удалённый именованный канал идёт не через порт самого приложения, а через SMB (TCP 445) — нужно не правило приложения, а правило на стороне файлового обмена (SMB).
Другое исключение — среды высокой безопасности, где исходящие явно переведены в блокировку по умолчанию. Такая конфигурация есть лишь в части организаций, но там даже клиентским приложениям нужно запрашивать исходящее правило.²

flowchart TB
    accTitle: Входящее правило нужно только той стороне, которая слушает
    accDescr: Если приложение только подключается как клиент, входящее правило как правило не нужно; если открывает порт и ждёт соединений, входящее правило регистрируют из установщика
    APP["Инвентаризировать обмен своего приложения"] --> Q{"Открывает порт и<br/>ждёт соединений?"}
    Q -- "Не слушает<br/>(подключается только как клиент)" --> C1["Входящее правило как правило не нужно<br/>Обратный трафик проходит как «ответ»"]
    Q -- "Слушает<br/>(серверный тип, приём обратного вызова)" --> S1["Входящее правило обязательно<br/>→ регистрировать из установщика (глава 5)"]
    C1 -.-> EX["Исключение: в средах высокой безопасности<br/>с исходящими, заблокированными по умолчанию, запросить исходящее правило"]

Рис. 1: Если порт слушает, входящее правило обязательно; клиентским соединениям как правило правило не нужно.

Случай «приложение вроде клиентское, а на деле ещё и слушает» (приём обратного вызова результата, точка приёма уведомлений от другого процесса и т. п.) легко пропустить. Если неясно, каким способом обмена слушает своё приложение, на этапе проектирования стоит свериться с «Как выбрать межпроцессное взаимодействие в Windows».

2.1. Профили и «расположение сети»

Правила применяются по профилю сети. Профилей три.¹

Профиль	Когда применяется	Типичное место
Домен	Автоматически, когда ПК, присоединённый к домену AD, обнаруживает контроллер домена. Вручную задать нельзя	Корпоративная доменная сеть
Частный	Администратор задаёт вручную на сетевом интерфейсе	Домашняя LAN, небольшой офис
Общедоступный	Значение по умолчанию для неопознанной сети. Спроектирован из самых жёстких предпосылок	Общественный Wi-Fi, отель, аэропорт

Какой профиль действует сейчас, смотрят Get-NetConnectionProfile; переключение частный/общедоступный — Set-NetConnectionProfile.¹ Частая авария на площадке: в workgroup-среде клиента сеть определилась как «общедоступная», и входящее правило, ограниченное доменом/частным, не применяется. Когда «правило есть, а не проходит», раньше содержимого правила подозревайте совпадение профиля.

2.2. Приоритет правил

Оценка при нескольких правилах — не взвешенный список порядка, а следующий последовательный принцип.²

Явное правило разрешения побеждает блокировку по умолчанию
Явное правило блокировки побеждает конфликтующее разрешение
В пределах, не противоречащих двум пунктам выше, побеждает более конкретное правило

Практический смысл: «если где-то есть одно блокирующее правило, сколько ни добавляй разрешающих позже — не победишь». Как видно в следующей главе, именно такое блокирующее правило тихо создаёт тот диалог.

3. Что на самом деле делает диалог «важного предупреждения» — почему нельзя доверять ему

Когда приложение впервые начинает слушать порт (listen) и для этого приложения нет ни разрешающего правила, ни правила, заданного администратором, Windows показывает знакомый диалог «Важное предупреждение системы безопасности Windows»: «Некоторые функции этого приложения блокируются брандмауэром Windows Defender». Спецификация поведения однозначна.²

Если показан пользователю с правами администратора: «Разрешить доступ» создаёт разрешающее правило. Но «Отмена» создаёт блокирующее правило. Обычно две штуки — для TCP и для UDP.
Если показан пользователю без прав администратора: при любом выборе создаётся блокирующее правило.
В обоих случаях пока созданное правило не удалено, диалог больше никогда не появляется, и связь продолжает блокироваться.

flowchart TB
    accTitle: Развилка диалога «важного предупреждения»
    accDescr: Если правила нет и входящие уведомления включены, появляется диалог; отмена или действие обычного пользователя создаёт блокирующее правило, и диалог больше никогда не появляется
    L["Приложение начинает слушать порт"] --> Q1{"Есть правило,<br/>совпадающее с этим приложением?"}
    Q1 -- "есть" --> R1["Следовать правилу<br/>(диалог не появляется)"]
    Q1 -- "нет" --> Q2{"Входящие уведомления<br/>включены?"}
    Q2 -- "выключены" --> R2["Молча блокировать<br/>(правило не создаётся)"]
    Q2 -- "включены" --> DLG["Диалог «важного предупреждения»"]
    DLG -- "администратор: «Разрешить доступ»" --> OK["Создаётся разрешающее правило"]
    DLG -- "администратор: «Отмена»" --> NG1["Создаётся блокирующее правило"]
    DLG -- "пользователь без прав администратора<br/>(при любом действии)" --> NG2["Создаётся блокирующее правило"]
    NG1 --> NEVER["Пока правило не удалено,<br/>диалог больше никогда не появится"]
    NG2 --> NEVER

Рис. 2: Отмена диалога или действие пользователя без прав впекает блокирующее правило; пока его не удалят, диалог больше не появится.

То есть диалог выглядит как «механизм спросить разрешение у пользователя», а на площадке бизнес-приложения работает как «механизм, который в момент касания обычным пользователем впекает блокирующее правило». Если внедряющий запустит в первый раз под учётной записью администратора и разрешит в диалоге, созданное разрешающее правило действует на весь ПК, и со следующего дня обычные пользователи пока связываются. Но аварии остаются — когда обычный пользователь первым наступит на прослушивание, которое при проверке внедрения не трогали; когда действующий сетевой профиль отличается от профиля при внедрении; когда обновление меняет путь exe (главы 4 и 5).

Сама Microsoft для устройств, которыми пользуются не администраторы, прямо указывает следующие лучшие практики.²

До первого запуска приложения разместить нужные правила (установщик или раздача со стороны управления)
Отключить входящие уведомления (если уведомления выключены, само автоматическое создание правил во время выполнения больше не происходит)

Отключение уведомлений — Set-NetFirewallProfile -NotifyOnListen False или групповая политика.⁷ «Когда появится диалог, пусть человек на площадке нажмёт разрешить» — не процедура эксплуатации, а бронь аварии. Входящее правило регистрируют при установке — это вывод этой статьи, и он совпадает с рекомендацией Microsoft.

4. Проектирование входящего правила — указание программы, порта, службы

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

Способ указания	Когда уместен	Слабость / оговорка
По программе (`program=` / `-Program`)	Порт прослушивания динамический или их несколько. Слушает само настольное приложение	Только полный путь exe, подстановочные знаки нельзя². Если обновление меняет путь, правило теряет цель (п. 5.4)
По порту (`localport=` / `-LocalPort`)	Порт фиксирован. Легко согласовать заявку в ИТ и настройки сетевого оборудования	Пропускает и другой процесс, слушающий тот же порт. Нужен реестр номеров портов
По службе (`-Service`)	Процесс прослушивания работает как служба Windows	Цель сужают коротким именем службы³. Нельзя для формы прямого запуска exe
Сочетание (программа + протокол + порт)	Базовая форма продакшен-бизнес-приложения	Чем больше условий, тем слабее к изменению среды (путь, порт) — содержимое правила документируйте²

Поверх этого накладывают ограничение области. Рекомендация Microsoft по проектированию тоже — «входящие правила насколько возможно конкретны».²

Ограничение профиля: входящее правило бизнес-приложения, которое используют только внутри компании, ограничивают доменом/частным и не включают на общедоступном. Это предотвращает аварию «ноутбук подключился к внешнему Wi-Fi — и порт прослушивания открылся миру».
Ограничение удалённого IP: если источник соединения известен, -RemoteAddress сужают до этой подсети. Для домашних и небольших сетей рекомендуется ограничение ключевым словом LocalSubnet.²³
Направление и число правил: если слушает только TCP, одного правила TCP достаточно. Не плодите по инерции пары TCP/UDP, как делает диалог.

«От нужного собеседника, на нужный порт, только нужная программа» — проектирование входящего правила сводится к этой одной фразе минимальных прав.

5. Практика регистрации из установщика — netsh и New-NetFirewallRule

5.1. Предпосылка: нужны права администратора

Добавление и удаление правил брандмауэра — изменение параметров всего компьютера, поэтому выполнять нужно с правами администратора (из повышенного процесса).⁸ Установщик обычно и так работает с правами администратора, поэтому регистрацию правила разумно класть внутрь установки. Причиной запускать само приложение от администратора это не является. Мышление этой границы подробно разобрано в «Когда нужны права администратора».

5.2. Регистрация через netsh advfirewall

Классика, которую удобно вызывать из любого установщика, — netsh advfirewall firewall add rule.⁸

rem add rule при одноимённом правиле дописывает ещё одно, поэтому перед
rem повторным запуском при переустановке, восстановлении и обновлении
rem одноимённое правило сначала удаляют, затем регистрируют заново
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem Разрешающее входящее: программа + порт + ограничение профиля
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem При удалении: удалить по имени
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule не заменяет существующее одноимённое правило, а добавляет ещё одно с тем же именем, поэтому без предварительного delete rule при каждом повторном запуске правила размножаются, и после обновления, сменившего путь или область, старое разрешающее правило выживает (при первом запуске ведущий delete rule отвечает, что совпадающего правила нет, но выполнение пакета продолжается, так что этот порядок нормален. Если установщик судит об успехе по коду выхода, смотрите результат хвостового add rule). Источник тоже можно сузить, например remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet.⁸ Удаление снимает все правила, совпавшие по имени, поэтому имя правила делайте уникальным с префиксом компании.

5.3. Регистрация через PowerShell (New-NetFirewallRule)

Для более тонкого управления — модуль NetSecurity. -DisplayName обязателен, -Profile принимает несколько значений через запятую (без пробела).³

# Регистрация (из установщика в повышенном состоянии). -Name — уникальный
# идентификатор, поэтому при повторном запуске переустановки, восстановления
# и обновления создание одноимённого правила даёт ошибку. Идемпотентность —
# удалить существующее одноимённое, затем создать заново
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 входящие)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# При удалении: не ошибаться, если правила нет
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

-Name указан явно не случайно. -Name — уникальный идентификатор правила; если опустить, назначается случайное значение. Отображаемое имя (-DisplayName) может меняться в зависимости от языкового стандарта, поэтому ключом, по которому скрипт находит правило, Microsoft указывает -Name.³ Чтобы деинсталлятор гарантированно снимал только своё правило, фиксацию -Name считайте обязательной.

5.4. Когда обновление меняет путь exe

Правило по программе фиксирует цель полным путём. То есть если обновление меняет каталог установки или имя exe, правило остаётся, но цель теряется, и прослушивание снова блокируется. Новый exe по новому пути при этом считается «приложением без правила», поэтому в среде с включёнными уведомлениями снова появляется диалог главы 3, и если им управляет обычный пользователь, впекается блокирующее правило. В среде, где уведомления отключены, как рекомендует глава 3, диалога нет — молча сбой. Особенно часто при размещении в папке с номером версии и при схемах самообновления, где место размещения двигается.

flowchart TB
    accTitle: Если обновление меняет путь exe, правило теряет цель
    accDescr: Правило по программе фиксирует полный путь, поэтому при смене места размещения цель теряется; в зависимости от уведомлений диалог появляется снова или связь молча блокируется
    V1["Внедрили v1.0<br/>правило указывает на exe в папке v1.0"] --> UP["Обновление размещает в папку v1.1<br/>путь исполняемого exe меняется"]
    UP --> MISS["Правило старого пути теряет цель<br/>(правило есть, но не действует)"]
    MISS --> Q{"Входящие уведомления<br/>включены?"}
    Q -- "включены" --> DLG["Диалог появляется снова<br/>обычный пользователь — блокирующее правило"]
    Q -- "выключены" --> SILENT["Диалога нет,<br/>молча блокируется"]
    MISS -.->|"мера"| FIX["Зафиксировать путь через обновления<br/>или в обработке обновления удалить старое правило и зарегистрировать заново"]

Рис. 3: Если обновление меняет путь exe, старое правило теряет цель; держите путь стабильным или регистрируйте заново при обновлении.

Мера проста — одно из двух.

Зафиксировать место установки, чтобы полный путь exe не менялся через обновления
При обновлении, которое меняет путь, updater удаляет старое правило и регистрирует по новому пути (команды 5.2/5.3 выполняют и в обработке обновления)

Для MSI регистрацию правила как правило встраивают как пользовательское действие, выполняемое после размещения файлов (при удалении — пользовательское действие на стороне удаления). В наборах вроде WiX есть расширения, которые описывают правила брандмауэра декларативно. Место реализации зависит от выбранного способа распространения, поэтому см. также «Как выбрать способ распространения Windows-приложения». Ещё одна классика внедрения у клиента — ложные срабатывания антивируса — в «Реакция на ложные срабатывания Microsoft Defender».

6. Устранение неполадок — поток разбора «не связывается»

Процедуру на момент обращения зафиксируйте по порядку. Общий поток такой.

flowchart TB
    accTitle: Разбор «не связывается»
    accDescr: По порядку проверяют прослушивание на сервере, достижимость с клиента, совпадение профиля, правила в ActiveStore и DROP в журнале
    S["«С клиента не связывается»"] --> N["На сервере: netstat -ano"]
    N -- "не слушает" --> APP["Проблема до брандмауэра<br/>смотреть приложение и службу"]
    N -- "LISTENING" --> T["На клиенте: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["Достижимость в порядке<br/>смотреть слой приложения (аутентификация, протокол)"]
    T -- "False" --> P["На сервере: Get-NetConnectionProfile<br/>проверить действующий профиль"]
    P -- "не совпадает с целью правила" --> FIXP["Пересмотреть указание профиля в правиле"]
    P -- "совпадает" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>есть ли разрешающее, нет ли блокирующего"]
    R --> LOGCHK["Зафиксировать отброс (DROP) в pfirewall.log"]

Рис. 4: Механический разбор: netstat → Test-NetConnection → профиль → правила ActiveStore → pfirewall.log.

Шаг	Команда / действие	Что проверить
1. Прослушивание (на сервере)	`netstat -ano`	Слушает ли целевой порт LISTENING. Если не слушает — проблема до брандмауэра
2. Достижимость (на клиенте)	`Test-NetConnection -ComputerName sv01 -Port 50051`	`TcpTestSucceeded` равен True?⁴
3. Профиль (на сервере)	`Get-NetConnectionProfile`	Совпадает ли действующий профиль с профилем, на котором правило включено¹
4. Действующие правила (на сервере)	`Get-NetFirewallRule -PolicyStore ActiveStore`	Есть ли целевое разрешающее среди «реально действующих», включая происходящие из GPO. Нет ли блокирующего от диалога⁵
5. Журнал (на сервере)	pfirewall.log	Отбрасываются ли (DROP) пакеты на целевой порт⁶

Дополнение к шагу 4. Условия порта и программы живут не в самом правиле, а в объектах фильтров, поэтому обратный поиск правила от порта идёт через фильтр.⁵⁷

# Обратный поиск правил, связанных с портом 50051
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# Проследить происхождение правила (локальное или GPO)
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

Журнал брандмауэра шага 5 (pfirewall.log) по умолчанию ничего не записывает. Путь по умолчанию — %windir%\system32\logfiles\firewall\pfirewall.log, максимальный размер по умолчанию — 4 096 КБ; запись начинается только после включения «записывать отброшенные пакеты» или «записывать успешные соединения».⁶ На одиночной машине включают так.⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

Журнал — текстовый файл: по строке — отброс (DROP) или разрешение (ALLOW), протокол, IP и порты источника и назначения, поэтому здесь фиксируют, «SYN с клиента дошёл и отброшен или вовсе не дошёл». В средах, где журнал задан политикой, иногда не хватает права записи в папку журнала (FullControl службы mpssvc) и файл не создаётся — тогда нужно создать папку и выдать ACL.⁶

Если копать глубже, включение политики аудита «Отброс пакетов платформы фильтрации» пишет событие безопасности 5152 на каждый отброс. Событий очень много, поэтому Microsoft рекомендует событие 5157 (соединение платформы фильтрации), которое пишется на соединение, а не на пакет. Это инструмент не повседневный, а на время разбора.⁹

Наконец, явно: сплошное отключение остановкой службы брандмауэра (MpsSvc) не поддерживается и вызывает проблемы на стороне ОС — меню «Пуск» не работает, сбоят обновления приложений Store. Если всё же нужно отключить и проверить, службу оставляют работающей и отключают профиль Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False, сразу возвращая после проверки.¹⁷ И когда причина — брандмауэр, мера — не увековечить отключение, а добавить одно правильное правило.

7. Оговорки под организационным управлением — среды, где локальные правила не действуют, и культура заявки

Даже если установщик зарегистрировал правило, есть среды, где оно не действует. В организациях, централизованно управляющих брандмауэром через GPO или Intune (CSP), по профилям можно отключить «слияние локальных правил» (AllowLocalPolicyMerge). Когда параметр отключён, правила, созданные локальным администратором (включая установщик), не применяются, и правила приложений, которым нужны входящие соединения, обязательно раздавать централизованно из GPO/CSP.²

flowchart TB
    accTitle: Если слияние локальных правил отключено, регистрация установщиком не действует
    accDescr: В среде с отключённым AllowLocalPolicyMerge локальные правила есть, но не применяются, поэтому переходят на централизованную раздачу через GPO или CSP
    GPOR["Правила, розданные через GPO/Intune"] --> EFF["Множество реально действующих правил<br/>(ActiveStore)"]
    LOCAL["Правила, созданные локально<br/>(включая регистрацию установщиком)"] --> Q{"Слияние локальных правил<br/>(AllowLocalPolicyMerge)"}
    Q -- "включено (по умолчанию)" --> EFF
    Q -- "отключено" --> DROP["Правило есть, но не применяется<br/>→ перейти на централизованную раздачу через GPO/CSP"]

Рис. 5: Если слияние локальных правил отключено, правила установщика не применяются; нужна централизованная раздача через GPO/CSP.

Реалистичная готовность со стороны разработки и внедрения такая.

Регистрацию правила в установщике проектировать как «не падает» (сама регистрация успешна, ошибкой не поймаете — в процедуру включите проверку связности после внедрения)
Шагом 4 главы 6 (-TracePolicyStore) смотреть, локальное происхождение у действующего правила или GPO⁵
Если ясно, что локальные правила не действуют, переключаться на заявку в ИТ на раздачу правила

В заявку передают следующий комплект. Правило брандмауэра можно создать только когда собраны направление, программа, порт и область — это и становится «сетевой спецификацией бизнес-приложения».

Пункт	Пример
Имя правила (идентификатор)	MyCompany-OrderServer-In
Направление	Входящие
Путь программы	C:\Program Files\MyCompany\OrderServer\OrderServer.exe
Протокол / порт	TCP 50051
Диапазон удалённых IP	172.16.10.0/24 (сегмент клиентов приёма заказов)
Профиль	Только домен
Назначение / основание	Приём соединений от клиента ввода заказов (имя бизнес-системы)
Условие снятия	Удалить при выводе этой системы

Со стороны ИТ объём работы при заявке с этой таблицей и без неё совершенно разный. Наоборот, «откройте, пожалуйста» с одним номером порта, как видно из главы 4, легко становится избыточным разрешением. Требования обмена вокруг файлового обмена и аутентификации в доменной среде ужесточаются и отдельно от брандмауэра (обязательность подписи и т. п.). См. также «Подпись SMB и привязка канала LDAP».

8. Итог

По умолчанию брандмауэр Windows — входящие блокировать, исходящие разрешать. Входящее правило нужно только приложениям серверного типа, которые слушают; если подключаетесь только как клиент, как правило не нужно.
Правила применяются по профилю (домен / частный / общедоступный). Первый подозреваемый в «правило есть, а не проходит» — несовпадение профиля.
Диалог «важного предупреждения» создаёт блокирующее правило при отмене или при действии пользователя без прав и больше не появляется. Продакшен-эксплуатацию этому диалогу доверять нельзя.
Входящие правила бизнес-приложения регистрируют из установщика — это единственный принцип. Регистрация — с правами администратора, с фиксированным -Name, включая удаление.
Правила строят вокруг программы + протокол + порт и сужают профилем и удалённым IP. Если обновление меняет путь exe, не забудьте перерегистрировать правило.
Разбор — механически в порядке netstat → Test-NetConnection → проверка профиля → Get-NetFirewallRule (ActiveStore) → pfirewall.log. Отключение остановкой службы не поддерживается.
Под управлением GPO/Intune слияние локальных правил может быть отключено. Тогда в ИТ подают заявку на раздачу, собрав имя правила, направление, программу, порт, удалённый IP и профиль.

Смежные области консультирования

KomuraSoft LLC занимается проектированием установщиков бизнес-приложений серверного типа (включая регистрацию и удаление правил брандмауэра), расследованием причин «не связывается» в среде клиента и упорядочиванием сетевых требований в расчёте на развёртывание под управлением GPO. Можно начинать уже с разбора «на машине разработки работает, у клиента — нет».

Справочные ссылки

Microsoft Learn, Windows Firewall overview. О том, что брандмауэр Windows — хостовый брандмауэр, включённый по умолчанию во всех редакциях; о поведении по умолчанию «входящие блокируются, кроме ответа на запрос или совпадения с правилом; исходящие разрешаются, кроме совпадения с правилом»; о трёх профилях (домен = автоматически при обнаружении контроллера домена, вручную задать нельзя; частный = задаёт администратор; общедоступный = значение по умолчанию для неопознанной сети); о проверке и смене категории сети через Get-NetConnectionProfile / Set-NetConnectionProfile; о том, что отключение остановкой службы брандмауэра (MpsSvc) не поддерживается и вызывает остановку меню «Пуск», сбой обновлений приложений Store и т. п.; о том, что правильное отключение — отключить профиль, оставив службу работающей. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Microsoft Learn, Windows Firewall rules. О приоритете правил (явное разрешение побеждает блокировку по умолчанию, явная блокировка побеждает разрешение, более конкретное побеждает, взвешенного порядка нет); о том, что при начале прослушивания приложением без правила появляется диалог; о том, что если пользователь-администратор выбирает «нет» или отмену, создаётся блокирующее правило (обычно две штуки TCP/UDP); о том, что у пользователя, который не локальный администратор, блокирующее правило создаётся независимо от выбора; о том, что пока созданное правило не удалено, диалог не появляется снова и связь блокируется; о том, что правило обычно добавляет само приложение или установщик; о рекомендации разместить правило до первого запуска и отключить входящие уведомления; о том, что в правилах по программе нельзя подстановочные знаки (C:*\teams.exe и т. п.), только полный путь; о том, что слияние локальных правил (AllowLocalPolicyMerge) можно отключить по профилю и тогда централизованная раздача правил приложений с входящими соединениями обязательна; о рекомендации делать входящие правила насколько возможно конкретными и для домашних и небольших сетей ограничивать удалённый адрес LocalSubnet; о том, что блокировка исходящих по умолчанию — вариант сред высокой безопасности, но входящие по умолчанию в разрешение менять нельзя. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³
Microsoft Learn, New-NetFirewallRule (NetSecurity). О том, что -DisplayName обязателен при создании правила; о том, что -Name — уникальный идентификатор, по умолчанию случайное значение, и в скриптах указано использовать -Name; о спецификации параметров -Direction (Inbound/Outbound), -Action (Allow/Block), -Program (полный путь), -Protocol (TCP/UDP/ICMPv4/ICMPv6/номер), -LocalPort, -RemoteAddress (IP/подсеть/диапазон/ключевые слова вроде LocalSubnet), -Service, -Profile (Any/Domain/Private/Public, несколько через запятую без пробела); о примере создания правила, сочетающего указание программы, протокола и порта. ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Test-NetConnection (NetTCPIP). О том, что Test-NetConnection — командлет, показывающий диагностику ping, TCP-соединения и маршрута; о проверке TCP-соединения на указанный порт через -ComputerName и -Port, результат возвращается как TcpTestSucceeded. ↩ ↩²
Microsoft Learn, Get-NetFirewallRule (NetSecurity). О том, что -PolicyStore ActiveStore получает правила всех применяемых хранилищ политик (итоговый набор, включая происходящие из GPO); о том, что условия порта, адреса и т. п. живут не в самом правиле, а в объектах фильтров, и запрос идёт через Get-NetFirewallPortFilter / Get-NetFirewallApplicationFilter; о том, что -TracePolicyStore показывает происхождение правила (PolicyStoreSource / PolicyStoreSourceType Local/GroupPolicy). ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Configure Windows Firewall logging. О том, что путь журнала по умолчанию — %windir%\system32\logfiles\firewall\pfirewall.log; о максимальном размере по умолчанию 4 096 КБ и удалении старых записей при достижении предела; о том, что журнал не пишется, пока не включено «отброшенные пакеты» или «успешные соединения»; о включении через netsh advfirewall set allprofiles logging droppedconnections/allowedconnections enable; о том, что без FullControl службы mpssvc на папку журнала файл может не создаться и тогда нужны ручное создание папки и выдача ACL. ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Manage Windows Firewall with the command line. О настройке поведения по умолчанию, уведомлений (-NotifyOnListen False) и журнала через Set-NetFirewallProfile; о примере создания правила по программе через New-NetFirewallRule и удаления через Remove-NetFirewallRule / netsh advfirewall firewall delete rule; о шаблоне подавления ошибки, когда правила нет, через -ErrorAction SilentlyContinue; о запросе обратного поиска правила по условию порта от Get-NetFirewallPortFilter; о том, что правильное отключение — Set-NetFirewallProfile -Enabled False. ↩ ↩² ↩³
Microsoft Learn, Use netsh advfirewall firewall context to control Windows Firewall behavior (KB947709). О примерах добавления правил по программе и порту синтаксисом netsh advfirewall firewall add rule (name= / dir=in / action=allow / program= / enable=yes / remoteip= / profile= / protocol= / localport=); о примере удаления через delete rule; о том, что член группы администраторов при включённом UAC должен выполнять из повышенного командного приглашения; о настройке журнала через netsh advfirewall set currentprofile logging. ↩ ↩² ↩³
Microsoft Learn, Audit Filtering Platform Packet Drop. О том, что при включении подкатегории аудита «Отброс пакетов платформы фильтрации» при отбросе пакета платформой фильтрации Windows пишутся события 5152 (и 5153); о том, что объём событий этой подкатегории очень велик и для наблюдения за заблокированными соединениями рекомендуется событие 5157, пишущееся на соединение, а не на пакет. ↩

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Практическое руководство по хранилищу сертификатов Windows — пользователь или компьютер, куда класть

Куда класть клиентский сертификат — в хранилище пользователя или компьютера? Практическое руководство, которое системно закрывает классич...

Читать статью

Политика аудита безопасности Windows и расследование журнала событий на практике — как стать ИТ-службой, которая умеет читать 4625

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

Читать статью

Практическое руководство по Windows LAPS — отказ от общего локального пароля администратора на всех ПК

Общий локальный пароль администратора на всех ПК — питательная среда для атак Pass-the-Hash, когда компрометация одной машины распростран...

Читать статью

OneDrive «Файлы по запросу» и бизнес-приложения — какие допущения ломают заполнители и как с этим жить

CSV с рабочего стола не открывается, или импорт падает с «файл не найден» — причина может быть в Known Folder Move и «Файлах по запросу» ...

Читать статью

Теневое копирование тома (VSS): устройство и практика — почему резервное копирование может скопировать файл, который ещё используется

Занятый файл обычно нельзя скопировать из-за нарушения совместного доступа — как тогда это делает ПО резервного копирования? Статья разби...

Читать статью

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Технические темы Windows

Раздел о разработке Windows, расследовании сбоев и использовании существующих активов.

Открыть тему

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Разработка приложений для Windows

Бизнес-приложения, интеграция оборудования и средства связи — от требований до разработки.

Открыть услугу Связаться с нами

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Нужно ли правило брандмауэра приложению, которое только подключается к серверу как клиент?: Как правило, нет. По умолчанию брандмауэр Windows — «входящие блокировать, исходящие разрешать», поэтому клиентское приложение, которое только само инициирует соединения наружу, при значениях по умолчанию связывается нормально. Входящее правило нужно только стороне, которая открывает порт и ждёт соединений, то есть приложениям серверного типа. Есть два исключения. В средах высокой безопасности исходящие тоже могут быть переведены в блокировку по умолчанию — тогда нужно запросить и исходящее правило. И даже «клиентское» приложение нуждается во входящем правиле для той части, которая сама слушает порт, чтобы принимать уведомления о результате.
Нельзя ли просто нажать «Разрешить доступ» в диалоге «Важное предупреждение системы безопасности Windows» и этим ограничиться?: На этот момент хватит, но продакшен-эксплуатацию этому доверить нельзя. Если пользователь с правами администратора отменит этот диалог, создаётся блокирующее правило. Хуже: если прав администратора нет, блокирующее правило создаётся при любом нажатии. Пока созданное правило не удалено, диалог больше не появляется, и связь продолжает сбоить. В бизнес-приложениях, где на площадке машиной управляет обычный конечный пользователь, состояние «кто-то один раз отменил — и с тех пор никогда не соединяется» возникает тривиально легко. Сама Microsoft рекомендует размещать правило до первого запуска приложения именно чтобы этого избежать.
Входящее правило строить вокруг порта или вокруг программы?: Базовый подход — сочетать, а не брать одно. Правила по программе фиксируют цель полным путём exe, но если обновление меняет путь, правило теряет цель (подстановочные знаки не поддерживаются). Правила по порту делают заявку в ИТ однозначной, но пропускают и любой другой процесс, который слушает тот же порт. Для продакшен-бизнес-приложения схема минимальных прав — ось «программа + протокол + порт», профиль ограничить Domain/Private, удалённый IP — подсетью клиента. Правило только по программе — когда порт динамический.
Правило, которое зарегистрировал наш установщик, на ПК клиента, кажется, не действует. Почему?: Вероятно, брандмауэр клиента централизованно управляется через GPO или Intune, и «слияние локальных правил» (AllowLocalPolicyMerge) отключено. Когда этот параметр отключён, правило, созданное локально, в профиле есть, но не применяется — правила можно раздавать только централизованно через GPO/CSP. Полный набор действующих правил смотрите Get-NetFirewallRule -PolicyStore ActiveStore и просите ИТ раздать правило. Заявка проходит с одного раза, если сразу передаёте имя правила, направление, путь программы, протокол и порт, диапазон удалённых IP и профиль.
Можно ли временно отключить брандмауэр ради разбора?: Отключение остановкой службы (MpsSvc) абсолютно исключайте. Эта операция не поддерживается Microsoft и вызывает проблемы на стороне ОС: перестаёт работать меню «Пуск», сбоят обновления приложений Store. Если для разбора всё же нужно отключить, правильный способ — оставить службу работающей и отключить профиль через Set-NetFirewallProfile -Enabled False. И это ограничьте несколькими минутами проверки, виноват ли брандмауэр, и сразу верните. Держать отключённым — менять всю защиту ПК на проблему, которую решило бы одно добавленное правило.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.

Открыть профиль Связаться с нами

Публичные ссылки

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Вернуться в блог

1. Сначала вывод

Карта знаний этой статьи

2. Точно зафиксировать поведение по умолчанию — входящие блокируются, исходящие разрешаются

2.1. Профили и «расположение сети»

2.2. Приоритет правил

3. Что на самом деле делает диалог «важного предупреждения» — почему нельзя доверять ему

4. Проектирование входящего правила — указание программы, порта, службы

5. Практика регистрации из установщика — netsh и New-NetFirewallRule

5.1. Предпосылка: нужны права администратора

5.2. Регистрация через netsh advfirewall

5.3. Регистрация через PowerShell (New-NetFirewallRule)

5.4. Когда обновление меняет путь exe

6. Устранение неполадок — поток разбора «не связывается»

7. Оговорки под организационным управлением — среды, где локальные правила не действуют, и культура заявки

8. Итог

Похожие статьи

Смежные области консультирования

Справочные ссылки

Похожие статьи

Практическое руководство по хранилищу сертификатов Windows — пользователь или компьютер, куда класть

Политика аудита безопасности Windows и расследование журнала событий на практике — как стать ИТ-службой, которая умеет читать 4625

Практическое руководство по Windows LAPS — отказ от общего локального пароля администратора на всех ПК

OneDrive «Файлы по запросу» и бизнес-приложения — какие допущения ломают заполнители и как с этим жить

Теневое копирование тома (VSS): устройство и практика — почему резервное копирование может скопировать файл, который ещё используется

Связанные темы

Технические темы Windows

Услуги по этой теме

Разработка приложений для Windows

Частые вопросы

Об авторе

Го Комура