Лише брандмауер Windows як аварійний вимикач VPN: чи витримає?

Запитайте, чи може брандмауер Windows сам служити аварійним вимикачем, і отримаєте дві впевнені та несумісні відповіді. Одна каже, що правило за типом інтерфейсу робить усю роботу; друга — що без скриптів це не працює. Обидві описують половину одного механізму. Брандмауер уміє виразити блокування, а чи справді результат закривається безпечно залежить від трьох речей: як Windows класифікує тунельний адаптер, чи зберігається виняток для кінцевої точки і чи покриті розв'язання імен та IPv6. Помилитеся хоч в одному — машина або протече, або втратить будь-який зв'язок.

Три умови, у цьому порядку

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

Друга умова — виняток для кінцевої точки. До появи будь-якого тунелю клієнт має дістатися сервера VPN через фізичний адаптер, тому суцільне блокування цього адаптера заважає саме тому з'єднанню, яке зробило б блокування непотрібним. Виняток має називати сервер і його порт, а пакет має виходити через фізичний шлюз, а не в ще не піднятий тунель.

Третє — покриття. Набір правил, який блокує IPv4 і забуває IPv6, або дозволяє локальному резолверу шукати кінцеву точку і тим самим дозволяє будь-який інший запит, відкрито відмовляє саме в тому вікні, для якого й існує вимикач. Це прогалина в проєктуванні, а не помилка брандмауера. Це ще й прогалина, яка переживає будь-який прогін тестів на столі.

Класифікація — перші ворота

Подивіться, що Windows думає про адаптери, перш ніж писати хоч одне правило. Вбудоване підключення VPN у Windows зазвичай виглядає як віддалений доступ. Клієнт сторонньої розробки, який створює власний віртуальний адаптер, часто виглядає дротовим, а отже, блокування, обмежене дротовими адаптерами, блокує і тунель.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

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

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

Винятку для кінцевої точки потрібен не лише правила, а й маршрут

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

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

Без маршруту виняток допомагає лише поки маршрут за замовчуванням ще вказує на фізичний шлюз. Щойно клієнт встановлює власний маршрут за замовчуванням і потім відключається, дозволеним пакетам нікуди розумно йти, і з'єднання не відновити. Ця відмова виглядає як зламаний клієнт, а насправді це відсутній маршрут.

Тримайте виняток настільки вузьким, наскільки дозволяє клієнт. Одна адреса і один порт піддаються перевірці; діапазон, що покриває всю мережу провайдера, — ні. Це ширше правило дозволяє і все інше, що розміщено в того самого провайдера, а це зазвичай більше, ніж задумано.

DNS і IPv6 — місця, де він відкрито відмовляє

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

IPv6 — друге. Правила, написані для IPv4, не покривають іншу родину, і багато клієнтів встановлюють лише маршрути IPv4. Тому машина з власним підключенням IPv6 може продовжувати говорити з інтернетом, поки бік IPv4 надійно заблокований, а вимикач увесь час повідомляє про успіх.

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

Тестуйте, зупиняючи клієнт, а не витягуючи кабель

Єдиний осмислений тест — той, що імітує відмову, від якої ви захищаєтеся. Зупиніть службу, убийте процес або вимкніть адаптер, створений клієнтом, потім спробуйте дістатися інтернету й імені:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

Усі три мають відмовити. Якщо перший удався, блокування не діє; якщо другий удався там, де перший відмовив, у вас витік DNS; якщо удався третій, IPv6 не покритий. Кожен результат указує рівно на одну з прогалин вище.

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

Якщо ворота класифікації або вимога DNS роблять підхід «лише брандмауер» непридатним, вимикач на боці клієнта — чесна відповідь. Якщо ж тунель закінчується на маршрутизаторі, політикою має володіти маршрутизатор, бо одне правило там покриває кожен пристрій за ним і не залежить від того, як Windows називає адаптер.