Как устранить блокировку сетевого доступа политикой организации в Windows

Сообщение «Сетевой доступ заблокирован политикой организации» не указывает на единственный источник проблемы. Ограничение может находиться на уровне сетевого адаптера, шлюза, маршрута, DNS, прокси-сервера, VPN, Windows Defender Firewall, антивируса, EDR-агента или доменной политики Group Policy.

Начните с проверки масштаба сбоя: откройте внутренний ресурс, внешний сайт, проверьте разрешение имени, доступность TCP-порта и работу проблемного приложения. Затем соберите вывод диагностических команд Windows: ipconfig /all, route print, nslookup, tracert и Test-NetConnection. Такой порядок помогает отличить неисправность подключения от запрета, заданного Active Directory, GPO, прокси или защитным агентом.

Не отключайте брандмауэр, VPN, прокси, антивирус или EDR без разрешения. Не удаляйте параметры реестра и службы Group Policy, чтобы обойти ограничение. Ошибка загрузки ISO Windows, блокировка Rufus программой Sentinel или предложение обратиться к администратору могут относиться к контролю приложений, обновлению или защите устройства, но сами по себе не доказывают наличие сетевой политики.

Что делать, если Windows сообщает о блокировке сетевого доступа

Рабочий алгоритм состоит из четырех действий: определить масштаб сбоя, зафиксировать контекст, проверить сетевой путь и сравнить настройки с применёнными политиками. Локальные параметры меняйте только после сохранения исходных значений и при наличии разрешения.

Определите масштаб проблемы за несколько минут

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

1. Проверьте адрес, маску, шлюз и DNS-серверы командой ipconfig /all.
2. Отправьте запрос к локальному шлюзу, например ping 192.168.1.1. Используйте фактический адрес шлюза из вывода предыдущей команды.
3. Проверьте внутреннее имя, например nslookup portal.company.local.
4. Проверьте внешний или разрешённый корпоративный ресурс по TCP, например Test-NetConnection portal.company.local -Port 443.
5. Сравните работу браузера и проблемного приложения. Браузер может использовать пользовательский прокси, а служба Windows или установщик, WinHTTP-прокси.
6. Если это допускает регламент, сравните Wi-Fi и Ethernet. Для VPN зафиксируйте результат до подключения и после подключения туннеля.

Интерпретация простая: отсутствие адреса или шлюза указывает на подключение и DHCP, доступный шлюз при неработающем TCP-порту переносит проверку к маршрутизации и фильтрации, ошибка разрешения имени указывает на DNS, а сбой одного приложения требует проверки WinHTTP, сертификатов и EDR.

Зафиксируйте сообщение, время и контекст сбоя

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

• дату и время первого сбоя, а также часовой пояс;
• имя компьютера и доменную учётную запись;
• имя приложения, процесс или службу;
• имя ресурса, порт и тип протокола;
• тип подключения, Wi-Fi, Ethernet или VPN;
• название VPN-клиента и состояние туннеля;
• наличие локальных прав администратора;
• недавние обновления Windows, антивируса, EDR, драйверов или VPN-клиента;
• результат проверки на другом компьютере или в другой разрешённой сети.

Запишите, что именно менялось перед сбоем. Сообщения об ошибках 0xc1900500 и 715-123130 при загрузке ISO, отказ Media Creation Tool, блокировка Rufus программой Sentinel и предложение обратиться к администратору нужно описывать как отдельные наблюдения. Они могут возникнуть из-за защиты приложений, проблем установщика или прав доступа.

Как понять, где возникает блокировка

Сетевой запрос проходит через последовательность уровней: сетевой адаптер, IP-конфигурация, шлюз и маршрут, DNS, прокси или VPN, локальный firewall и антивирус, затем сервер и политика самого приложения. Проверяйте уровни именно в таком порядке.

Сетевой адаптер и сетевой профиль

Проверьте, поднят ли интерфейс и получил ли он параметры от DHCP или заданной конфигурации.

Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MacAddress -AutoSize
Get-NetIPConfiguration
Get-NetConnectionProfile

В ipconfig /all найдите IPv4-адрес, маску, шлюз по умолчанию и DNS-серверы. Адрес из диапазона 169.254.x.x обычно означает, что компьютер не получил адрес от DHCP. Отсутствие шлюза ограничивает доступ за пределами локального сегмента.

Команда Get-NetConnectionProfile показывает категорию сети: Public, Private или DomainAuthenticated. Профиль влияет на набор правил Windows Defender Firewall. Публичный профиль не доказывает наличие доменной блокировки, а DomainAuthenticated подтверждает распознавание доменной сети, но не объясняет отказ конкретного приложения.

Маршрутизация и доступность узла

Сначала проверьте шлюз, затем таблицу маршрутов и путь к целевому узлу.

ping 192.168.1.1
route print
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric
tracert -d portal.company.local
Test-NetConnection portal.company.local -Port 443 -InformationLevel Detailed

Если шлюз не отвечает, проверьте кабель, Wi-Fi, VLAN, изоляцию беспроводных клиентов и DHCP. Ответ шлюза при недоступном внешнем ресурсе переносит поиск к маршруту, VPN-шлюзу, прокси или фильтрации.

Маршрут с низкой метрикой через виртуальный VPN-адаптер может направлять весь трафик в туннель. При split tunneling часть подсетей идёт через VPN, а внешний трафик использует обычный шлюз. При full tunnel внешний трафик передаётся через корпоративный шлюз безопасности. Не исправляйте маршруты вручную, если их задаёт VPN-клиент или GPO.

Отсутствие ответа на ping не доказывает блокировку TCP. Сервер или firewall могут фильтровать ICMP и принимать TCP-соединения. Для веб-сервиса используйте Test-NetConnection с портом 443, для RDP, SSH или другого сервиса укажите фактический порт.

DNS, прокси и прикладной запрос

DNS может возвращать адрес внутреннего фильтра, отвечать с ошибкой NXDOMAIN, завершаться тайм-аутом или разрешать внутренние имена только через корпоративный сервер.

Get-DnsClientServerAddress
nslookup portal.company.local
Resolve-DnsName portal.company.local
Resolve-DnsName repo.company.local -Type A

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

Если имя разрешается, проверьте порт. Если порт доступен, а приложение сообщает об ошибке, ищите проблему в прокси, сертификате, авторизации или политике процесса. Подключение к HTTPS по IP может завершиться ошибкой сертификата, поэтому такой тест показывает сетевой путь, но не подтверждает корректность веб-сеанса.

Для браузерных сбоев полезна отдельная диагностика проблем с загрузкой файлов в браузерах, где разделены проверки браузера, прокси, VPN, антивируса и сетевых параметров.

Команды для диагностики сети Windows

Выполняйте команды последовательно и сохраняйте вывод. Большинство перечисленных проверок только читает состояние системы. Команды, которые обновляют аренду DHCP, сбрасывают кэш или меняют настройки, запускайте после согласования.

Проверка адаптера и IP-конфигурации

ipconfig /all
Get-NetAdapter
Get-NetIPConfiguration
Get-NetConnectionProfile

• Status со значением Up показывает активное состояние интерфейса, но не подтверждает доступ к нужному ресурсу.
• IPv4-адрес 169.254.x.x указывает на отсутствие нормальной DHCP-конфигурации, если адрес не назначен намеренно.
• Отсутствие Default Gateway ограничивает маршрутизацию во внешние сети.
• Пустой список DNS-серверов или адрес неизвестного интерфейса требует проверки DHCP, VPN и статических параметров.
• Несколько активных виртуальных адаптеров могут менять метрики маршрутов. Это часто видно после установки VPN, Docker, Hyper-V или другого сетевого ПО.

Состояние физического линка проверяйте отдельно. Активный интерфейс с адресом ещё не означает, что коммутатор разрешил доступ к нужному VLAN.

Проверка шлюза и таблицы маршрутов

ping 192.168.1.1
route print
Get-NetRoute -AddressFamily IPv4
tracert -d portal.company.local
Test-NetConnection portal.company.local -Port 443

Подставьте адрес шлюза из ipconfig /all. В route print найдите маршрут 0.0.0.0 для IPv4 и проверьте интерфейс, шлюз и метрику. Для внутреннего ресурса ищите более специфичный маршрут, например подсеть корпоративного сервиса.

Команда tracert -d не тратит время на обратное разрешение имён и показывает переходы быстрее. Звёздочки на промежуточном узле могут означать фильтрацию ICMP. Если Test-NetConnection показывает TcpTestSucceeded : True, сетевой порт отвечает независимо от результата ping.

Проверка DNS-разрешения

nslookup portal.company.local
nslookup repo.company.local
Resolve-DnsName portal.company.local -Type A
Resolve-DnsName portal.company.local -Type AAAA

Смотрите, какой DNS-сервер указан в ответе, сколько времени занял запрос и какой результат вернулся. Тайм-ауты указывают на недоступность DNS или фильтрацию UDP/TCP 53. NXDOMAIN означает, что сервер не знает запрошенное имя или намеренно скрывает его. Ошибка SERVFAIL требует проверки самого DNS-сервера, делегирования зоны или DNSSEC.

Если внутреннее имя не разрешается без VPN, подключите разрешённый VPN-клиент и повторите команду. После подключения должны измениться DNS-серверы или суффиксы поиска, если корпоративная схема использует отдельные зоны.

Проверка доступности порта и приложения

Test-NetConnection portal.company.local -Port 443 -InformationLevel Detailed
Test-NetConnection repo.company.local -Port 22 -InformationLevel Detailed
Test-NetConnection 10.20.10.15 -Port 443

Параметр RemoteAddress показывает, в какой IP преобразовалось имя, а InterfaceAlias помогает увидеть использованный интерфейс. При TcpTestSucceeded : False проверьте маршрут, порт на сервере, локальный firewall, прокси и фильтр трафика.

Успешный TCP-тест подтверждает установление соединения, но не проверяет TLS, HTTP-ответ, авторизацию и права пользователя. Приложение может использовать другой порт, собственный прокси или сертификатное хранилище.

Для передачи результатов сохраните базовый вывод в отдельные файлы:

ipconfig /all > ipconfig.txt
route print > route.txt
nslookup portal.company.local > dns.txt
gpresult /h gpresult.html /f

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

Проверка прокси-сервера Windows: как отключить прокси в Windows

Прокси бывает пользовательским, системным WinHTTP или автоматическим, через PAC-файл. Один параметр не всегда влияет на все приложения. Браузер может работать через WinINet или собственные настройки, а служба Windows использует WinHTTP.

Проверьте ручной прокси и автоматическую настройку

Откройте Параметры > Сеть и Интернет > Прокси. Проверьте три области:

• автоматическое определение параметров;
• сценарий настройки, URL PAC-файла и доступность сервера конфигурации;
• ручной прокси, имя или IP-адрес, порт и список исключений.

Неверный PAC-файл часто даёт смешанный результат: часть сайтов открывается, внутренние адреса работают, а внешний ресурс получает ошибку прокси. Ошибка в исключениях способна направить корпоративный адрес напрямую, хотя политика требует прокси.

Отключение прокси в Windows допустимо использовать как краткую диагностическую проверку только с разрешения администратора. Перед тестом запишите адрес, порт, PAC-файл и исключения. После проверки верните исходные параметры, если прямое соединение не разрешено политикой.

Если поля недоступны, значение возвращается после перезагрузки или снова появляется после обновления политик, настройка, вероятно, приходит через GPO, MDM или защитный агент. Локальная правка в таком случае не устраняет причину.

Проверьте системный WinHTTP-прокси

netsh winhttp show proxy

В выводе может быть указан прямой доступ, конкретный прокси или сценарий автоматической настройки. Сравните результат с пользовательским прокси. Ситуация «браузер работает, а установщик или служба Windows не подключается» часто возникает из-за различий между WinINet и WinHTTP.

Команда netsh winhttp reset proxy удаляет системную настройку WinHTTP. Не запускайте её на рабочей станции без согласования: через этот прокси могут идти обновления, телеметрия защиты, запросы к репозиториям и служебные соединения.

Определите, задан ли прокси политикой организации

Сравните состояние настройки до и после входа в домен, перезагрузки и обновления политик. Если значение появляется снова, сформируйте отчёт gpresult и передайте его администратору.

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

Проверка VPN, DNS, брандмауэра и антивируса

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

VPN и виртуальные сетевые адаптеры

Get-VpnConnection
Get-VpnConnection -AllUserConnection
Get-NetAdapter | Where-Object {$_.Name -match 'VPN|WireGuard|TAP|TUN|Cisco|AnyConnect'}
route print

Сравните DNS, маршруты и доступность ресурсов до и после подключения VPN. Проверьте, появился ли маршрут к корпоративной подсети, изменился ли шлюз и какой интерфейс указан в Test-NetConnection.

При split tunneling корпоративные сети идут через VPN, а разрешённый внешний трафик остаётся на обычном шлюзе. При full tunnel весь трафик передаётся через шлюз безопасности. Ручное добавление маршрута способно нарушить контроль доступа и привести к потере соединения.

Если VPN подключён, но внутренний ресурс не открывается, проверьте срок действия учётной записи, MFA, DNS-зоны и правила доступа к конкретной подсети. Перезапускайте только согласованный VPN-клиент.

DNS-фильтрация и внутренние зоны

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

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName portal.company.local
Resolve-DnsName blocked-name.example -Type A

Не меняйте DNS на публичный сервер как способ обхода фильтра. Это может сломать разрешение имён Active Directory, обнаружение контроллеров домена и доступ к внутренним репозиториям.

Брандмауэр Windows и правила профиля

Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction
netsh advfirewall show allprofiles
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 50

Сравните состояние профилей Domain, Private и Public. Проверяйте исходящие правила для конкретного процесса, порта или адреса, а не выключайте firewall полностью. В доменной среде правила могут приходить через GPO, поэтому локальное изменение быстро вернётся или не применится.

Журнал firewall полезен, если политика разрешает аудит блокировок. Для поиска события используйте время сбоя, имя процесса, локальный порт и адрес назначения. Отсутствие записи не исключает блокировку на прокси, сетевом шлюзе или EDR.

Антивирус и защитный агент

Endpoint-защита может блокировать процесс, домен, сертификат, загрузку файла или сетевой канал. Откройте журнал антивируса, EDR или web-фильтра и найдите запись с тем же временем, что указано в диагностике.

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

Не добавляйте исключение, не разрешайте неизвестный процесс и не отключайте web-фильтр самостоятельно. Если ошибка связана с TLS, проверьте, не перехватывает ли трафик защитный агент и установлен ли корпоративный корневой сертификат по правилам организации.

Для отказов сервисов аутентификации пригодится шпаргалка по проверке сети, DNS, proxy и TLS. Она помогает отделить сетевой отказ от ошибки IdP или сертификата.

Проверка политик сетевого доступа Windows и доменных ограничений

Доменная политика может задавать прокси, правила Windows Defender Firewall, параметры VPN, DNS, ограничения приложений, сетевой профиль и требования безопасности. На рабочем компьютере источник настройки нужно подтвердить, а не угадывать по тексту уведомления.

Получите отчёт о применённых политиках

gpresult /r /scope:computer
gpresult /r /scope:user
gpresult /h gpresult.html /f

В текстовом отчёте ищите применённые GPO и разделы, связанные с Internet Settings, Proxy, Windows Defender Firewall, AppLocker, ограничениями приложений и параметрами безопасности. HTML-отчёт удобнее передавать администратору и сопоставлять с рабочей станцией, где проблема отсутствует.

Оснастка rsop.msc показывает результирующий набор политик в графическом виде. Она помогает увидеть фактически применённые параметры, но не заменяет анализ журналов прокси, VPN и защитного агента.

Отличите доменную политику от локальной настройки

Проверьте, что происходит после перезагрузки и обновления политик. Если доступно и разрешено регламентом, администратор может запустить gpupdate /force, после чего нужно повторить проверку и сохранить время обновления.

Признаки централизованной настройки:

• поля прокси или firewall недоступны для редактирования;
• значение возвращается после перезагрузки или gpupdate;
• та же настройка встречается на других компьютерах с аналогичной ролью;
• в отчёте gpresult указана конкретная GPO;
• защитный агент восстанавливает правило после локальной правки.

Не удаляйте ключи реестра, не отключайте службы Group Policy и не удаляйте доменные политики с компьютера. Такие действия нарушают контроль конфигурации и могут оставить рабочую станцию без обязательных средств защиты.

Когда нужно обращаться к администратору

Передайте проблему в IT-службу или администратору домена, если настройка заблокирована, возвращается после изменения, блокируется приложение защитным агентом, требуется открыть порт или нарушен доступ к корпоративному сервису.

В обращение включите:

• имя компьютера и пользователя;
• точный текст ошибки и время сбоя;
• имя ресурса, IP-адрес при наличии и порт;
• состояние VPN и тип подключения;
• вывод ipconfig /all, route print, DNS-проверок и Test-NetConnection;
• отчёт gpresult;
• идентификатор события антивируса, EDR или firewall;
• описание уже выполненных действий.

Не отправляйте пароли, токены, приватные ключи и полные дампы, если их не запросили по защищённой процедуре.

Безопасные действия на рабочем компьютере

Пользователь может собрать факты и устранить ряд обратимых локальных сбоев. Изменение сетевой архитектуры, правил защиты и доменной конфигурации требует согласования.

Что можно проверить без изменения политики

• плотность подключения кабеля и состояние Wi-Fi;
• активный сетевой адаптер и наличие IPv4-адреса;
• шлюз, DNS-серверы и таблицу маршрутов;
• доступность нужного TCP-порта через Test-NetConnection;
• состояние разрешённого VPN-клиента;
• события Windows, firewall, антивируса и EDR;
• результат после повторной аутентификации в VPN;
• результат после синхронизации политики, если такую проверку разрешила IT-служба.

Переподключение кабеля, выбор разрешённой Wi-Fi-сети и повторный запуск согласованного VPN-клиента обычно не меняют доменную политику. Зафиксируйте исходные параметры до действия и сравните их после.

Очистку DNS-кэша командой ipconfig /flushdns выполняйте только по правилам организации. Команда не меняет DNS-сервер и не снимает фильтрацию, она удаляет локальные сохранённые ответы.

Какие действия требуют согласования

Получите разрешение перед тем, как:

• отключать ручной или автоматический прокси;
• менять DNS-серверы и статические маршруты;
• отключать VPN или менять режим split tunneling;
• выключать Windows Defender Firewall;
• приостанавливать антивирус, EDR или web-фильтр;
• добавлять исключения для приложения, домена или порта;
• удалять корпоративные сертификаты;
• использовать сброс сетевых параметров Windows;
• изменять параметры реестра, служб и локальных политик.

Сброс сети Windows может удалить виртуальные адаптеры, настройки VPN и сохранённые параметры. На доменном компьютере это способно привести к дополнительному инциденту, поэтому применяйте его только по процедуре восстановления.

Типовые сценарии и порядок локализации неисправности

Сопоставьте симптом с уровнем проверки и выберите минимальный набор действий. Полный перебор параметров увеличивает риск изменить рабочую конфигурацию.

Сайты не открываются, но шлюз доступен

Проверьте разрешение имени и TCP-порт 443. Если DNS не возвращает адрес, изучайте корпоративный DNS и VPN. Если имя разрешается, но порт закрыт, проверьте прокси, web-фильтр, маршрут и события защитного агента.

Если по имени ресурс не открывается, а известный IP отвечает на TCP-проверку, причина может находиться в DNS или фильтрации доменов. HTTPS по IP используйте только как сетевой тест, потому что сертификат сайта может не соответствовать адресу.

Для отдельной панели управления сетевого устройства, NAS или сервера используйте алгоритм диагностики доступа к веб-интерфейсу.

Браузер работает, а приложение не подключается

Работа браузера подтверждает доступ только для его маршрута, прокси и набора сертификатов. Приложение может использовать WinHTTP, собственный прокси, другой DNS, отдельный порт или собственное хранилище сертификатов.

Сначала выполните netsh winhttp show proxy, затем проверьте порт назначения через Test-NetConnection. После этого сопоставьте время ошибки с журналом антивируса, EDR и самого приложения.

Если проблема возникает при входе в корпоративный сервис, проверьте DNS, VPN и TLS по пошаговой инструкции для сервисов аутентификации. Не добавляйте исключение для приложения, пока администратор не подтвердит безопасную причину блокировки.

Внутренние ресурсы доступны только через VPN

Сравните таблицу маршрутов, DNS-серверы и результат TCP-проверки до и после подключения VPN. Для внутреннего ресурса должны появиться корректный маршрут и DNS-ответ, если корпоративная сеть использует отдельные зоны.

Проверьте, не истёк ли сертификат VPN, не изменился ли профиль подключения и разрешён ли доступ вашей учётной записи к нужной подсети. При full tunnel не меняйте маршруты вручную.

Если нужен независимый тестовый стенд, не подключённый к рабочей сети, его можно разместить на отдельном VDS или в облачной инфраструктуре Timeweb Cloud. Такой стенд помогает проверить доступность сервиса с другого сегмента, но не заменяет согласование корпоративного доступа и не должен использоваться для обхода политики.

Настройка прокси или firewall возвращается после изменения

Зафиксируйте момент, когда параметр восстановился. Сопоставьте его с перезагрузкой, входом пользователя, запуском VPN и обновлением политик.

Сформируйте gpresult /h gpresult.html /f, сохраните состояние профилей firewall и приложите журналы защитного агента. Если отчёт указывает на GPO, изменение должно выполняться в центральной политике, а не на одном компьютере.

Если GPO не указана, но правило возвращает EDR или MDM, передайте администратору имя агента, идентификатор события и точное время восстановления. Не отключайте службы управления конфигурацией.

Как подтвердить восстановление доступа

Сбой считается устранённым после повторной проверки того же ресурса, приложения и порта. Открытие одного сайта не подтверждает исправность всей сети.

Контрольный набор проверок после исправления

1. Повторите Resolve-DnsName или nslookup для проблемного имени.
2. Проверьте маршрут и интерфейс командой route print или Get-NetRoute.
3. Запустите Test-NetConnection с тем же узлом и портом.
4. Откройте ресурс или запустите приложение в штатном режиме.
5. Проверьте состояние VPN, прокси и сетевого профиля.
6. Убедитесь, что firewall, антивирус и EDR работают в требуемом режиме.
7. Повторите тест после переподключения сети, перезагрузки или обновления политики, если это предусмотрено регламентом.
8. Проверьте журналы на новые блокировки.

Если доступ восстановился только до перезагрузки, после отключения VPN или до следующего обновления GPO, причина осталась. Зафиксируйте это поведение и передайте администратору.

Что указать в итоговом отчёте

Запишите исходный симптом, найденный уровень блокировки и действие, которое вернуло доступ. Укажите, изменились ли параметры после перезагрузки и обновления политик.

Дата и время сбоя:
Компьютер и пользователь:
Ресурс, приложение и порт:
Тип подключения:
Состояние VPN:
Исходный симптом:
Проверенный слой:
Выполненные команды:
Обнаруженное правило или событие:
Изменённые параметры:
Результат после исправления:
Результат после перезагрузки:
Действия администратора:

Такой отчёт сокращает повторные проверки и показывает, кто менял конфигурацию. Если блокировка повторится, сравните новый вывод с сохранёнными файлами и ищите первое отличие во времени.