Профілі брандмауера й вихід VPN: чому загальнодоступний не є шляхом
Профіль брандмауера вибирає, який набір правил застосовується. Він нічого не каже про те, який інтерфейс ніс пакет, а явне блокування важливіше за вужчий дозвіл.
Правило звучить точно: дозволити локальний трафік у приватному профілі й лише трафік VPN у загальнодоступному. Це не так, бо мережевий профіль вибирає, який набір правил брандмауера застосовується, і нічого не каже про те, який адаптер ніс пакет. Ставлення до назви профілю як до вимоги шляху це та сама помилка, через яку проєкт з обмеженим виходом виглядає завершеним, хоча він не завершений.
Спочатку запишіть потоки, потім вирішіть, який механізм справді може забезпечити кожен із них. Цей список потоків єдиний артефакт, що переживе наступну зміну правил.
Категорія вибирає правила, а не маршрути
Коли Windows класифікує мережу як загальнодоступну або приватну, брандмауер застосовує набір правил, налаштований для цього профілю. Класифікація йде за мережею, до якої приєднався адаптер, а набір правил вирішує, що в ній дозволено. Жоден із цих фактів не залежить від того, чи трафік застосунку використовував тунель. Саме ця незалежність і є вся складність.
Вибір шляху виконує маршрутизація, через метрику інтерфейсу й префікс, який встановлює тунель. Тому профіль може бути позначений як загальнодоступний, поки з'єднання застосунку йде фізичним шляхом, і брандмауер усе одно повідомить, що застосовано загальнодоступний набір правил.
Тому правило, обмежене профілем, не може означати лише тунель. Ці дві властивості вирішують різні компоненти, і одна не може замінити іншу.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Явне блокування важливіше за вужчий дозвіл
Настанови Microsoft щодо правил брандмауера розрізняють дозвіл як виняток із дії блокування за замовчуванням і явне блокування, що суперечить дозволу. Явні блокування виграють цю суперечність, і вихідні правила підкоряються тому самому пріоритету.
Тож популярний рецепт додати правило, що блокує все, і покластися на вужчий дозвіл, розміщений вище, не робить того, чого очікує його автор. Брандмауер Windows не розв'язує суперечність за порядком правил, призначеним адміністратором. Блокування просто діє, а застосунок, що підключається, повідомляє про вичерпання часу очікування. Правило, схоже на виняток, ніколи не брало участі.
Підтримувана форма це політика заборони за замовчуванням зі схваленими дозвільними правилами, де кожен дозвіл називає програму, службу або призначення достатньо точно, щоб його можна було переглянути. Такий проєкт витримує аудит, бо кожен виняток видно і жоден не залежить від порядку створення.
Два правила, що суперечать одне одному, гірші за одне правило, бо підсумкова поведінка одночасно коректна й незрозуміла.
Дайте вихідній політиці одного власника
Підтримуваний клієнт VPN уже підтримує власну поведінку блокування та власні винятки для кінцевих точок. Додавання неузгоджених ручних правил може залишити цей клієнт поза тунелем, потрібним йому для налаштування, або залишити відкритим другий шлях, якого ніхто не помітив.
Вирішіть, кому належить вихідна політика, перш ніж писати правила: власній конфігурації клієнта, керованій політиці брандмауера або задокументованому локальному списку винятків із власником. Потім узгодьте шари, замість того щоб накопичувати експерименти, доки щось не підключиться. Названий власник це також той, кого питають, коли два шари розходяться.
Збережіть канал відновлення, перш ніж щось змінювати. Віддалена машина, заблокована поза власним шляхом керування, це гірший результат, ніж прогалина в політиці, яку ви закривали. Правило відновлення легше обґрунтувати, коли воно записане заздалегідь, і легше знайти, коли зміна йде не так у годину, яку ніхто не любить.
Перевірте чотири результати замість читання мітки
Політика хороша настільки, наскільки вона розрізняє випадки, тому ставтеся до мітки профілю як до відправної точки, а не як до результату. Чотири результати скажуть, чи працює вона: потрібний запит LAN проходить, охоплений інтернет-запит проходить, заборонений прямий запит не проходить, а випадок відмови тунелю поводиться так, як задумано, замість тихого відкату. Запишіть чотири результати поруч зі зміною правил. План тестування з чотирма названими випадками достатньо короткий, щоб запускати його щоразу, і достатньо конкретний, щоб гучно провалитися.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
Перша команда показує, як класифіковано кожну підключену мережу, що часто не збігається з припущенням людини, яка писала правило. Друга показує дію за замовчуванням для кожного профілю, а третя перелічує ввімкнені вихідні блокування, зокрема ті, що тихо скасують вужчий дозвіл.
Запустіть чотири випадки знову після зміни мережі, бо профіль може бути перекласифікований, коли машина підключається до іншої мережі. Збіг мітки профілю не є доказом, що шлях був тим, який ви задумали.