Настройка брандмауэра Windows 11: правила для входящих и исходящих подключений

Брандмауэр Windows 11 блокирует входящие подключения по умолчанию и разрешает исходящие. Всё остальное поведение системы описывается правилами: что фильтруется (программа, порт, протокол, IP-адрес), каким действием (разрешить или блокировать) и в каком сетевом профиле. Открыть доступ к веб-серверу означает создать входящее правило для TCP 80 и 443. Запретить программе выход в интернет означает создать блокирующее исходящее правило.

Разница между этими задачами сводится к двум параметрам: направление трафика и профиль сети. Ошибка в любом из них даёт эффект «правило есть, но не работает»: в офисе сервис открыт, дома тот же сервер недоступен, потому что Windows пометила сеть как общественную.

Дальше: логика фильтрации, пошаговые сценарии для оснастки wf.msc и PowerShell, приоритет разрешающих и блокирующих правил, проверка результата по журналам и командлетам NetSecurity. Принцип работы фильтрации един для актуальных сборок Windows 11; между версиями меняется набор предопределённых правил, а не сама механика. Так, в Windows 11 24H2 изменилось поведение по умолчанию при создании SMB-ресурса: раньше создание общей папки автоматически включало правила группы File and Printer Sharing для соответствующих профилей, теперь это поведение изменено (What's new in Windows 11 IoT Enterprise, version 24H2). Прямых подтверждений неизменности механики для 22H2 и 23H2 в доступных источниках нет, поэтому ориентируйтесь на свою сборку и проверяйте поведение на стенде.

Как работает брандмауэр Windows 11: логика фильтрации трафика

Брандмауэр Защитника Windows работает как фильтр с отслеживанием состояния (stateful). Первое подключение проверяется по набору правил, а само соединение запоминается в таблице состояний. Пакеты ответа и данные внутри уже разрешённой сессии пропускаются без отдельного правила. Поэтому открытие входящего порта 443 не требует парного исходящего правила для ответов сервера. Это поведение подтверждается документацией Microsoft: брандмауэр отслеживает активные сетевые соединения, и возвратный трафик распознаётся как часть уже установленного соединения и обычно пропускается (Windows Firewall Rules | Microsoft Learn).

В основе лежат два неявных (implicit) правила: весь входящий трафик блокируется, если нет явного разрешения, весь исходящий разрешается, если нет явного запрета. Незапрошенный входящий трафик блокируется, если он не является ответом на инициированный компьютером трафик или не соответствует разрешающему правилу. По умолчанию Windows Firewall разрешает весь исходящий сетевой трафик, если он не соответствует запрещающему правилу (Configure Firewall Rules With Group Policy | Microsoft Learn). Поскольку действует действие блокировки входящего трафика по умолчанию, для разрешения трафика необходимо создавать входящие правила-исключения (Windows Firewall Rules | Microsoft Learn).

Каждое правило описывает трафик по нескольким признакам: программа (путь к исполняемому файлу), служба, протокол (TCP, UDP, ICMP), локальный и удалённый порт, локальный и удалённый IP-адрес, сетевой профиль, тип интерфейса. Совпадение по всем заданным признакам запускает действие: разрешить или блокировать. Аналогия простая: вахтёр пропускает тех, кто есть в списке, и разворачивает остальных. Список - это правила, вход - порт.

Входящие и исходящие правила: в чём разница и когда что использовать

Ключ - кто инициировал соединение. Входящее правило обрабатывает попытки подключиться к этому компьютеру извне: HTTP-запрос к веб-серверу, сессию RDP, обращение по SMB, эхо-запрос ICMP. Исходящее правило контролирует соединения, которые запускает локальный компьютер: браузер к сайту, клиент обновлений к серверу вендора, DNS-запросы, телеметрию.

Исключения, где одного правила мало, связаны с протоколами обратных подключений. В активном режиме FTP сервер сам открывает соединение к клиенту, поэтому кроме входящего правила на порт 21 нужны разрешения на диапазон портов данных. Похожая логика у SIP, части P2P-протоколов и игровых сервисов.

Для тонкого контроля исходящий трафик ограничивают точечно: политика «разрешить всё» остаётся по умолчанию, но для конкретных приложений создаются правила с действием «Блокировать». Массовая замена исходящего разрешения на запрет требует полной инвентаризации трафика, иначе ломаются обновления, доменные аутентификации и резервное копирование.

Сетевые профили: домен, частная и общественная сеть

Windows ведёт три независимых набора правил, по одному на профиль:

• Домен - сеть, в которой компьютер видит контроллер домена Active Directory. Профиль включается автоматически, правила обычно распространяются групповой политикой.
• Частная - доверенная сеть: домашняя, офисная без домена, лабораторный стенд. Здесь разрешены сетевое обнаружение и общий доступ.
• Общественная - недоверенные сети: кафе, аэропорт, гостиница. Обнаружение и общий доступ ограничены, входящие правила максимально жёсткие.

Профиль назначается сетевому подключению, а не компьютеру. Если Ethernet подключён к доменной сети, а Wi-Fi к гостевой, у каждого интерфейса будет свой активный профиль, и применяются оба набора правил, каждый к своему интерфейсу. Проверить состояние: Get-NetConnectionProfile. Сменить профиль вручную: Set-NetConnectionProfile -InterfaceAlias "Wi-Fi" -NetworkCategory Private.

Правило привязывается к одному профилю, к двум или ко всем трём. При активном профиле применяются только привязанные к нему правила. Пример: правило для RDP разумно разрешать для профилей «Домен» и «Частная». Привязка RDP к «Общественной» открывает порт 3389 в любой гостиничной сети, где окажется ноутбук.

Частая причина неработающих правил: при подключении к новой сети Windows по умолчанию помечает её общественной. Правило, привязанное только к «Домен», в таком сценарии не сработает. Проверяйте активный профиль перед разбором конфликтов, а правила для внутренних сервисов привязывайте к нескольким профилям сразу. Полезный разбор этой логики с чек-листом для RDP, SMB и VPN собран в руководстве настройка брандмауэра Windows: правила, профили и диагностика.

Пошаговое создание правила для входящих подключений: открываем порт для веб-сервера

Задача: Windows 11 с IIS, Nginx или другим сервером на портах 80 и 443 должен принимать HTTP и HTTPS из локальной сети, но не из интернета.

1. Запустите оснастку: Win+R, введите wf.msc, нажмите Enter и подтвердите повышение прав. Откроется «Монитор брандмауэра Защитника Windows в режиме повышенной безопасности».
2. В левой панели выберите «Правила для входящих подключений», в правой - «Создать правило…».
3. Тип правила: «Для порта».
4. Протокол и порты: TCP, пункт «Определённые локальные порты», значение 80,443 без пробелов.
5. Действие: «Разрешить подключение».
6. Профиль: снимите галочку «Общественная», оставьте «Домен» и «Частная».
7. Имя и описание: например Web 80-443 inbound, в описании укажите цель, дату создания и ответственного.

Опция «Блокировать подключение, если оно не защищено» на шаге действия требует IPsec-защиты канала. Без настроенного IPsec на обоих концах соединение просто не пройдёт, поэтому включайте её только в инфраструктуре с развёрнутым IPsec.

Проверка результата: с другого компьютера выполните Test-NetConnection -ComputerName 192.168.1.50 -Port 443 или telnet 192.168.1.50 443. Внутри системы состав правила виден командой Get-NetFirewallRule -DisplayName "Web 80-443" | Get-NetFirewallPortFilter. Проверка с того же хоста по адресу 127.0.0.1 проблему не покажет: брандмауэр Windows обычно пропускает петлевой трафик по умолчанию, хотя отдельные средства защиты или параметры групповой политики могут влиять на это поведение. Изменения применяются сразу, перезагрузка не нужна.

Ограничение доступа по IP-адресам для веб-сервера

Открывать порт для всех адресов не обязательно. Откройте свойства созданного правила двойным щелчком и перейдите на вкладку «Область». В разделе «Удалённый IP-адрес» выберите «Указанные IP-адреса» и добавьте нужные значения: отдельный адрес 10.0.0.15, подсеть 192.168.1.0/24 или диапазон 10.0.0.10-10.0.0.50. Каждое значение вводится отдельной строкой.

В том же окне есть раздел «Локальный IP-адрес»: на сервере с несколькими сетевыми картами правило привязывают к конкретному адресу, например к внутреннему интерфейсу. Трафик, пришедший на внешний интерфейс, под такое правило не попадёт.

Ограничение по IP требует сопровождения. При смене адресов клиентов (DHCP, переезд офиса в другую подсеть) правило перестаёт пропускать трафик, и это выглядит как отказ сервиса. В доменных сетях вместо отдельных адресов надёжнее указывать подсети, а перечень исключений держать в описании правила или во внешней документации.

Блокировка приложения с помощью брандмауэра Windows 11

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

1. В оснастке wf.msc выберите «Правила для исходящих подключений» - «Создать правило…».
2. Тип правила: «Для программы».
3. Путь к программе: укажите полный путь к исполняемому файлу через «Обзор».
4. Действие: «Блокировать подключение».
5. Профиль: отметьте нужные профили, чаще всего все три.
6. Имя и описание: например Block app X outbound.
7. Повторите шаги для «Правил для входящих подключений», если приложение слушает входящие соединения.

Путь указывается к конкретному файлу. После крупного обновления программы он может измениться, если версия входит в имя каталога, и правило перестанет действовать. Для служб используйте вкладку «Программы и службы» в свойствах правила: там выбирается конкретная служба, а для svchost.exe - отдельный сервис из списка. Блокировать svchost.exe целиком нельзя: под ним работают сетевые компоненты системы, и общий запрет отключит сеть.

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

Как заблокировать приложение только для определённого сетевого профиля

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

Windows переключает активный профиль автоматически при смене сети, поэтому правило вступает в силу без ручного вмешательства. Эквивалент из PowerShell: New-NetFirewallRule -DisplayName "Client block public" -Direction Outbound -Program "C:\Program Files\Client\client.exe" -Action Block -Profile Public.

Управление правилами: редактирование, удаление и приоритет

Редактирование начинается с двойного щелчка по правилу. Доступны вкладки «Общие» (имя, описание, включено, действие), «Программы и службы», «Протоколы и порты», «Область», «Дополнительно» (профили, типы интерфейсов, edge traversal), а также «Пользователи» и «Компьютеры» для доменных сценариев с подписанными соединениями. Изменения применяются сразу после нажатия «ОК».

Отключение вместо удаления: снимите галочку «Включить правило» на вкладке «Общие». Правило останется в списке, но выпадет из фильтрации. Это удобный способ проверить гипотезу о конфликте: отключите подозрительное правило и повторите тест. Через PowerShell то же действие выполняет Set-NetFirewallRule -DisplayName "Web 80-443" -Enabled False.

Удаление: выделите правило и нажмите «Удалить» в правой панели либо выполните Remove-NetFirewallRule -DisplayName "Web 80-443". Перед удалением проверьте, не входит ли правило в группу, созданную групповой политикой: такие правила вернутся при следующем обновлении политики, и локальное удаление ничего не даст. Встроенные правила Windows (группы «Основные сети», «Удалённый рабочий стол», «Файл и принтер») удалять не стоит: без них перестают работать функции системы.

Приоритет устроен иначе, чем в iptables: нумерации и порядка выполнения в брандмауэре Windows нет, положение правила в списке на результат не влияет. Windows Firewall не поддерживает взвешенное, назначаемое администратором упорядочивание правил (Windows Firewall Rules | Microsoft Learn). Логика такая:

• Если трафик совпал с правилом «Блокировать», он блокируется, даже когда одновременно совпал с разрешающим правилом. Явно заданные правила блокировки имеют приоритет над любыми конфликтующими разрешающими правилами (Windows Firewall Rules | Microsoft Learn).
• Если блокирующих совпадений нет, но есть разрешающее, трафик пропускается.
• Если совпадений нет, работают неявные правила: входящий трафик блокируется, исходящий разрешается.

Более специфичные правила (по программе, порту и адресу) выигрывают у общих разрешений, но против явной блокировки это не помогает. Диагностику всегда начинают с поиска блокирующего правила, а не с проверки разрешающего.

Экспорт и импорт правил для резервного копирования

В wf.msc щёлкните правой кнопкой по узлу «Монитор брандмауэра Защитника Windows в режиме повышенной безопасности» и выберите «Экспортировать политику». Файл с расширением .wfw содержит все правила всех профилей и настройки журналирования. Обратная операция - «Импортировать политику»: текущая локальная конфигурация заменяется содержимым файла.

Эквивалент из командной строки: netsh advfirewall export "C:\backup\fw-policy.wfw" и netsh advfirewall import "C:\backup\fw-policy.wfw". Для переноса отдельных правил служат Export-NetFirewallRule и Import-NetFirewallRule: они работают с конкретным правилом и сохраняют его в отдельный файл.

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

Типичные ошибки при настройке брандмауэра Windows 11 и их предотвращение

• Порты открыты для всех профилей. Разрешение на 80, 443 или 3389 во всех трёх профилях делает сервис доступным в любой сети, включая публичные. Что делать: привязывайте правила к «Домен» и «Частная», а доступ извне закрывайте на периметре.
• Блокировка системных служб. Запрет исходящих подключений для svchost.exe, службы BITS или DNS-сервиса ломает обновления, разрешение имён и сеть. Сначала определите, какой процесс и какая служба обслуживают трафик, и блокируйте конкретную службу, а не контейнер.
• Неверный профиль. Правило, привязанное к «Домен», не работает в домашней сети. Проверяйте активный профиль командой Get-NetConnectionProfile и привязывайте правило к нескольким профилям.
• Ставка на блокировку приложения как на полный запрет. Программа может ходить в сеть через системную службу, дочерний процесс или прокси. После блокировки проверьте трафик по журналу и убедитесь, что соединений нет.
• Протоколы с обратными соединениями. Активный режим FTP, SIP и часть P2P-сценариев требуют входящих правил для соединений со стороны удалённого узла. Для FTP проще перейти в пассивный режим и задать диапазон портов данных.
• Отсутствие проверки после изменений. Правило создано, но не включено, порт указан как UDP вместо TCP, адрес задан в IPv6 вместо IPv4. Тестируйте результат с внешнего узла сразу после правки.
• Сторонний антивирус или файрвол. Продукт с собственной фильтрацией может перевести встроенный брандмауэр Windows в неактивное состояние, и его правила перестанут применяться. Состояние профилей показывает Get-NetFirewallProfile.

Документация и резервные копии снимают половину этих рисков: храните .wfw-файл с последней рабочей политикой, фиксируйте в описании правила цель и дату, помечайте временные правила для последующего удаления. Типовые сценарии блокировки RDP, SMB, VPN и серверных сервисов с чек-листом проверки разобраны в материале правила, профили и диагностика брандмауэра Windows.

Как не потерять удалённый доступ к серверу при настройке брандмауэра

Порядок действий, который снижает риск остаться без доступа:

1. Создайте разрешающее входящее правило для RDP (TCP 3389) до любых других изменений, с ограничением по адресу администратора: New-NetFirewallRule -DisplayName "RDP-Admin" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 10.0.0.5 -Action Allow -Profile Any.
2. Убедитесь, что правило включено и привязано к нужным профилям: Get-NetFirewallRule -DisplayName "RDP-Admin" | Get-NetFirewallAddressFilter.
3. Сохраните текущую политику в .wfw-файл: это точка возврата.
4. Подготовьте доступ вне полосы: KVM/IPMI, консоль гипервизора или физическую консоль. При блокировке сети он остаётся единственным способом попасть на машину.
5. Настройте автоматический откат. Запланированная задача, которая через 10 минут импортирует сохранённый .wfw-файл, вернёт доступ, если после правки связь с сервером пропала.

Новое правило RDP проверяйте во втором окне подключения, не закрывая текущую сессию. Откат в этом случае занимает секунды, а не требует перезагрузки сервера.

Проверка и мониторинг работы брандмауэра

Get-NetFirewallProfile выводит три профиля с ключевыми параметрами: Enabled, DefaultInboundAction, DefaultOutboundAction, LogAllowed, LogBlocked, LogFileName. Команда Get-NetFirewallRule -Direction Inbound -Enabled True показывает включённые входящие правила, добавьте -Action Block, чтобы увидеть только запреты. Состав конкретного правила виден через связку Get-NetFirewallRule -DisplayName "Web 80-443" | Get-NetFirewallPortFilter.

Проверка доступности порта с внешнего узла: Test-NetConnection -ComputerName server01 -Port 443. Если на сервере менялись и брандмауэр, и служба, проверяйте по шагам: сначала прослушивание порта, затем прохождение фильтра. Прослушивание видно так: Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess.

Журналирование включается в wf.msc: правый щелчок по узлу оснастки, «Свойства», вкладка «Параметры журнала», отдельная настройка для каждого профиля. По умолчанию файл лежит в %systemroot%\system32\LogFiles\Firewall\pfirewall.log, задайте предельный размер, чтобы он не рос бесконечно. Записи со статусом DROP показывают трафик, который не прошёл, с адресом источника, портом назначения и протоколом.

Журнал событий: «Просмотр событий» - «Журналы приложений и служб» - Microsoft - Windows - Windows Firewall With Advanced Security - Firewall. Здесь видно изменения политики и срабатывания правил. Узел «Мониторинг» в самой оснастке показывает активный профиль, состояние брандмауэра и число применяемых правил. Когда нужно понять, доходит ли пакет до узла, используйте встроенное средство pktmon или анализатор трафика вроде Wireshark.

Запись успешных подключений на сервере с интенсивным трафиком даёт большой объём логов и нагрузку на диск. Включайте LogAllowed на время диагностики, а LogBlocked оставляйте постоянно: именно эти записи показывают, что именно отклонил фильтр.

Диагностика: почему правило не работает

Проверяйте по порядку:

1. Активный профиль: Get-NetConnectionProfile. Привязано ли правило к этому профилю.
2. Состояние правила: галочка «Включить правило» или Enabled со значением True.
3. Направление: трафик входящий или исходящий. Правило другого направления не сработает.
4. Протокол и порт: приложение может слушать другой порт. Сопоставьте PID из Get-NetTCPConnection с процессом.
5. Адрес прослушивания: если служба слушает только 127.0.0.1, внешние подключения невозможны, и брандмауэр тут ни при чём. Исправляется настройкой самого приложения.
6. Конфликт с запретом: Get-NetFirewallRule -Action Block -Enabled True покажет блокирующие правила, которые перекрывают разрешение.
7. Сторонний файрвол: убедитесь, что фильтрацию выполняет встроенный брандмауэр, а не продукт антивируса.
8. Семейство адресов: правило для IPv4 не покрывает IPv6, если тип интерфейса не задан явно.

Временное отключение брандмауэра как метод диагностики допустимо только на изолированном стенде: на боевом сервере это открывает все порты. Безопасная альтернатива - разрешающее правило, ограниченное одним адресом администратора, которое снимается после теста. Отдельная категория причин связана с ситуациями, когда сервис молчит даже при выключенном файрволе, и с безопасным откатом изменений: они разобраны в инструкции файрвол Windows 10 и 11: как включить, отключить и настроить.

Материал описывает встроенный брандмауэр Защитника Windows в Windows 11 и не охватывает сторонние продукты фильтрации. Перед правкой политики на боевом сервере проверяйте шаги на стенде и держите под рукой резервную копию в .wfw и доступ вне полосы.

Рабочий цикл на сервере выглядит так: сохранить .wfw-файл, создать правило доступа для администратора, внести изменения, проверить порт с внешнего узла командой Test-NetConnection, удалить временные правила. Цикл занимает несколько минут и убирает большинство сценариев потери доступа и незаметно открытых портов.