Профили брандмауэра и выход VPN: почему общедоступный не путь

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

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

Категория выбирает правила, а не маршруты

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

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

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

Явная блокировка важнее более узкого разрешения

Руководство 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

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

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