Почему ваш VPN-адаптер остаётся в общедоступном профиле брандмауэра

Туннель поднят, учётная запись прошла проверку подлинности в домене, а Windows по-прежнему помечает подключение как общедоступное. Поэтому правило брандмауэра, написанное для доменного профиля, не применяется, и общая папка остаётся недоступной. Обычная попытка исправления — переключить адаптер в частный режим, что меняет набор действующих правил, но ничего не меняет в проверке подлинности. И метка, и исправление понимаются широко неверно, а чтобы их разделить, нужны три команды.

Учётная запись, которая подключилась, — это не категория сети

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

Успешная доменная проверка подлинности на шлюзе — это доказательство об учётной записи. Это не доказательство того, что конечная точка проверила сеть на контроллере домена, а именно это и означает доменная категория.

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

Три категории, одну из которых нельзя задать

Windows предлагает три категории, и только две из них может назначить администратор. Третью определяет операционная система после успешной проверки сети на контроллере домена.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Третья команда завершается ошибкой, и это документированное поведение, а не проблема прав. Справка самой команды указывает, что доменную категорию нельзя назначить таким способом, потому что Windows выводит её из доменной проверки подлинности. Увидеть ошибку — полезное подтверждение того, что категория является следствием, а не настройкой.

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

Правила следуют профилю, для которого написаны

Когда категория известна, недостающий доступ обычно объясняет себя сам. У каждого правила брандмауэра Windows есть область профиля, и правило, ограниченное доменом, не действует, когда интерфейс общедоступен. Три команды превращают это в ответ, а не в теорию, и третья ловит случай, когда профиль никогда не был проблемой:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

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

Определите, какая машина применяет правило

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

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

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

Что делать вместо переименования всего

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

Если цель — дать конкретной службе доступ к клиентам VPN, ограничьте правило по удалённому адресу, а не по профилю. Это точно выражает намерение, работает независимо от классификации и не зависит от того, угадает ли Windows виртуальный адаптер. Оно также переживёт обновление клиента, которое переклассифицирует интерфейс. Запишите пул в правило, и следующий человек прочитает намерение, не спрашивая.

Если доменная категория действительно ожидается и никогда не появляется, это отдельное расследование. Проверьте, что машина в домене, что она достигает контроллера домена через туннель и что защищённый канал в порядке. Эти три команды отвечают на это без единой правки реестра:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

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