Файрвол Windows Server для VPN-туннеля: правильная настройка

MAATRIX

Поднял VPN-сервер на Windows — и тут же встаёт вопрос: а что вообще должно торчать наружу? Открыл слишком много — сервер начинает получать сканы портов и попытки перебора уже в первый час после старта. Закрыл слишком много — сам себе отрезал доступ и полез перезагружать сервер через панель хостера. Штатный Windows Defender Firewall решает обе проблемы, если настроить его по понятной схеме: снаружи открыт один-единственный порт туннеля, всё остальное управления и сервисов видно только изнутри VPN. Разберём эту схему по шагам — через графический интерфейс и через PowerShell, с готовыми правилами, которые можно скопировать и применить.

Базовые принципы: закрыто всё, кроме необходимого

Правильная отправная точка для сервера в облаке — по умолчанию входящий трафик заблокирован полностью, и каждое разрешение вы добавляете осознанно, а не потому что «так проще». Windows Defender Firewall уже настроен в эту сторону из коробки: входящие подключения блокируются, если для них нет явного разрешающего правила. Задача — не ослаблять эту защиту, а точечно пробить в ней ровно те отверстия, которые нужны туннелю и вам самим.

Для сервера-VPN-шлюза список необходимого короткий. Снаружи, из открытого интернета, должен быть виден только один порт — тот, на котором слушает служба VPN: UDP 51820 для WireGuard или UDP/TCP 1194 для классического OpenVPN. Это единственная дверь, через которую подключаются клиенты — семья, офис, ваши устройства для доступа к ИИ-сервисам через туннель. Всё остальное — RDP для администрирования, порты приложений, файловые шары — не должно быть доступно из публичного интернета. Доступ к этим сервисам вы получаете уже находясь внутри туннеля, с адреса из VPN-подсети.

Такая модель убирает почти весь фоновый шум атак. Боты и сканеры, которые прощупывают случайные IP-адреса, ищут открытый RDP на 3389, SMB на 445, RPC на 135 — и просто не находят их, потому что порты не отвечают снаружи. Единственное, что они видят, — закрытый UDP-порт туннеля, который выглядит как молчащий адрес без запущенных служб. Если самого туннеля ещё нет, сначала имеет смысл поднять его — процесс разобран в статье про установку WireGuard на Windows Server, а здесь речь именно о файрволе вокруг уже работающего VPN.

Работа с Windows Defender Firewall: GUI и PowerShell

У штатного файрвола Windows два интерфейса управления, и разумно знать оба. Графическая консоль вызывается командой wf.msc — "Windows Defender Firewall with Advanced Security". Наберите её в строке "Выполнить" (Win+R) или в PowerShell. Консоль состоит из трёх узлов: "Правила для входящих подключений", "Правила для исходящих подключений" и "Правила безопасности подключения". Для VPN-туннеля работать вы будете почти исключительно с первым узлом, потому что именно он определяет, что видно снаружи.

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

Для повторяемой настройки удобнее PowerShell: одна команда New-NetFirewallRule создаёт правило целиком, со всеми параметрами, и её легко сохранить в скрипт для будущих серверов. Посмотреть, что уже настроено, можно так:

Get-NetFirewallRule -Direction Inbound -Enabled True | Select-Object DisplayName, Direction, Action, Profile

Эта команда выведет все активные правила для входящих подключений — полезно перед тем, как что-то менять, чтобы увидеть исходную картину и не наплодить дублей. Дальше все примеры в статье даны в PowerShell — их можно выполнить по очереди на любом Windows Server начиная с 2016-й версии.

Правило для VPN-порта и правило для RDP

Первое, главное правило — открыть входящий порт туннеля. Для WireGuard на стандартном порту 51820:

New-NetFirewallRule -DisplayName "VPN WireGuard Inbound" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow -Profile Any

Для OpenVPN на UDP-порту 1194 команда аналогична, только меняется номер порта и, при необходимости, протокол на TCP:

New-NetFirewallRule -DisplayName "VPN OpenVPN Inbound" -Direction Inbound -Protocol UDP -LocalPort 1194 -Action Allow -Profile Any

Это единственное правило, которое должно принимать подключения из "Any" — то есть из всего интернета, потому что клиенты туннеля подключаются с разных, часто меняющихся IP-адресов, и заранее сузить источник нельзя.

Второе правило устроено ровно наоборот: оно ограничивает доступ, а не открывает его. RDP на порту 3389 нужен для администрирования сервера, но открывать его всему интернету — одна из самых частых причин компрометации Windows-серверов, потому что перебор паролей на RDP идёт непрерывно. Правильная схема — доступ к RDP только с адресов из VPN-подсети, например 10.8.0.0/24:

New-NetFirewallRule -DisplayName "RDP only from VPN subnet" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 10.8.0.0/24 -Action Allow -Profile Any

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

Профили Domain/Private/Public — почему это важно в облаке

Windows Defender Firewall хранит три независимых набора правил — по одному на каждый сетевой профиль: Domain (сервер в домене Active Directory), Private (доверенная сеть, например домашняя) и Public (недоверенная сеть — по умолчанию так Windows классифицирует большинство новых подключений). У каждого профиля свои настройки по умолчанию, и правило, созданное для одного профиля, не действует в другом, если явно не указано иное.

Для сервера в облаке этот момент имеет прямое практическое значение. Сетевой адаптер такого сервера почти всегда определяется системой как профиль Public — просто потому что он не состоит в домене и не находится в "домашней" сети. Профиль Public по умолчанию самый строгий: блокирует всё, для чего нет явного разрешения, и это в целом правильно для интернет-фасада. Но именно из-за этого правило, которое вы создали и протестировали, может внезапно "не работать" — если при создании указали -Profile Domain или -Profile Private, а сетевой профиль сервера на самом деле Public.

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

Get-NetConnectionProfile

Она покажет имя сети, интерфейс и текущую категорию — Public, Private или DomainAuthenticated. Если сервер внезапно перестал принимать RDP или VPN-подключения после перезагрузки, первое, что стоит проверить, — не поменялся ли профиль сети и не оказалось ли нужное правило привязанным к профилю, который сейчас неактивен.

Логирование блокировок для диагностики

Когда правило "должно работать", но не работает, догадки — плохая стратегия отладки. Windows Defender Firewall умеет вести журнал заблокированных и разрешённых пакетов, и включение этого журнала обычно быстрее приводит к ответу, чем перебор вариантов вручную:

Set-NetFirewallProfile -Profile Public -LogBlocked True -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall_public.log" -LogMaxSizeKilobytes 4096

Аналогичные команды с -Profile Private и -Profile Domain включат логирование для остальных профилей. После включения файл начнёт заполняться строками с временем, действием (DROP или ALLOW), протоколом, адресами и портами — этого обычно достаточно, чтобы увидеть, достучался ли клиент туннеля до сервера и где именно пакет был отброшен.

Смотреть журнал удобно через PowerShell, отфильтровав только отброшенные пакеты:

Get-Content "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall_public.log" -Tail 50 | Select-String "DROP"

Держать подробное логирование включённым постоянно не обязательно — файл растёт, а полезной информации после первичной отладки становится всё меньше. Разумная практика — включать логирование на время диагностики конкретной проблемы и выключать после того, как правило починено, возвращая -LogBlocked False.

Типичные ошибки

Несколько сценариев повторяются у тех, кто настраивает файрвол под VPN-туннель впервые. Открыли входящий порт для VPN, но забыли про исходящий трафик — по умолчанию исходящие подключения разрешены глобально, но если на сервере ранее включили политику "блокировать по умолчанию" для исходящих, туннель поднимется, а трафик через него не пойдёт, потому что ответные пакеты службы VPN блокируются на выходе. Проверить это можно командой Get-NetFirewallProfile | Select-Object Name, DefaultOutboundAction — если там Block, нужно вернуть Allow или явно разрешить исходящий трафик для процесса VPN-службы.

Второй частый случай — дублирующиеся правила. Через GUI создали правило для порта 51820, потом через PowerShell создали ещё одно для того же порта с другим именем — оба активны, оба разрешают одно и то же, и разобраться через полгода, какое из них "настоящее", уже сложно. Перед добавлением нового правила стоит проверить существующие командой Get-NetFirewallRule -DisplayName "*VPN*" и отредактировать найденное через Set-NetFirewallRule, а не плодить копии.

Третья ошибка — понадеяться, что раз сервер "в облаке за NAT провайдера", профиль сети автоматически Private или Domain, и написать правила под этот профиль. На практике облачный адаптер почти всегда получает профиль Public, и привязанное к другому профилю правило просто не сработает. И последняя, менее очевидная: оставить RDP открытым "на всякий случай, вдруг VPN отвалится" — если такая ситуация пугает, разумнее держать под рукой доступ через консоль хостера (KVM/VNC в панели), а не держать RDP открытым для всего интернета.

Частые вопросы