Чому ваш 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

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