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

«На машине разработчика всё работает, а после установки у заказчика клиент не соединяется с сервером.» «При первом запуске выскочило какое-то предупреждение, и человек на объекте вроде нажал Отмена.» «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 может быть выключено «объединение локальных правил», и тогда локальные правила не действуют. Попросите ИТ распространить правило централизованно.¹²

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 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/>(сервер, приём callback)" --> S1["Входящее правило обязательно<br/>→ зарегистрировать из установщика (гл. 5)"]
    C1 -.-> EX["Исключение: если исходящие по умолчанию блокируются,<br/>запросить исходящее правило"]

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

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

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

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

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

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

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

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

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

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 сама для устройств, которыми пользуются не администраторы, прямо указывает следующие лучшие практики.²

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

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

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

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

Поверх этого накладывают ограничение области. Рекомендация 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.

Дополнение к шагу 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⁵
• Если ясно, что локальные правила не действуют, переключаться на заявку в ИТ на распространение правила

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

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

8. Итог

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

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

• Как выбрать межпроцессное взаимодействие в Windows — таблица решений: именованные каналы / TCP / gRPC / разделяемая память / COM
• Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/собственный updater
• Когда на Windows действительно требуются права администратора — UAC, защищённые области и как это определить на этапе проектирования
• Если ваше Windows-приложение приняли за вирус — как реагировать на ложные срабатывания Microsoft Defender и жить с влиянием на производительность
• Подпись SMB и привязка канала LDAP — на практике закрыть «вторую половину» мер против NTLM
• Как создавать и эксплуатировать службы Windows — от выбора между планировщиком заданий и службами до превращения BackgroundService в службу Windows

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

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

• Разработка приложений для 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.