WireGuard на Windows Server: установка и настройка

MAATRIX

Почти все инструкции по WireGuard написаны под Linux: apt install, systemd-юнит, iptables. Если в аренде у вас Windows Server и нужен защищённый туннель — до RDP, до внутренней сети офиса или до конкретной службы, — команды из линуксовых гайдов просто не подойдут: другая установка, другая генерация ключей, другой firewall. Ниже — пошаговая настройка WireGuard именно на Windows Server: клиент, ключи через GUI и PowerShell, конфиг туннеля, служба с автозапуском и правила Windows Firewall, которые оставляют открытым только нужный UDP-порт.

Зачем WireGuard на Windows Server

Стандартный сценарий администрирования Windows Server — RDP на порту 3389, открытый наружу. Это удобно, но опасно: порт 3389 непрерывно сканируют боты, подбирают пароли, эксплуатируют свежие уязвимости RDP-стека. Даже со сложным паролем и включённой NLA открытый наружу RDP — постоянная точка атаки. Базовую защиту сервера мы разбирали в статье про аренду и настройку Windows-сервера в России.

WireGuard решает это иначе, чем смена порта или блокировки по попыткам входа. Порт 3389 закрывается в firewall для всего интернета, а доступ к нему остаётся только через VPN-туннель: снаружи виден один UDP-порт WireGuard, который не отвечает ничего осмысленного на сканирование и не палит, что за ним вообще есть RDP. Подключиться к рабочему столу может только тот, у кого есть ключ и кто уже внутри туннеля.

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

Скачивание и установка официального клиента WireGuard для Windows

Ставить нужно только официальный клиент с сайта wireguard.com — сторонние сборки и «зеркала» не гарантируют оригинальный код. Разработчик держит на сайте всегда один, самый актуальный инсталлятор и не публикует архив старых версий, поэтому конкретный номер версии не важен: скачивайте то, что сайт предлагает на момент установки.

Порядок действий одинаков для десктопной Windows и Windows Server (2016, 2019, 2022, 2025):

1. Скачайте .msi-инсталлятор с официальной страницы загрузок.
2. Запустите файл от имени администратора — иначе установщик откажется ставить драйвер туннельного адаптера.
3. Согласитесь на установку WinTun-драйвера — виртуального сетевого адаптера для трафика туннеля.
4. Дождитесь завершения — в трее появится иконка WireGuard, а в меню «Пуск» — само приложение.

На Server Core без графической оболочки GUI-инсталлятор не подойдёт — пакет ставится через msiexec /i wireguard-installer.msi /quiet, а туннелями дальше управляют только из командной строки. На обычной Windows Server с рабочим столом (Desktop Experience) всё ставится и настраивается через GUI, как на клиентской Windows.

Генерация пары ключей через GUI или wg genkey/wg pubkey в PowerShell

Проще всего сгенерировать ключи прямо в приложении. Откройте WireGuard, нажмите «Добавить туннель → Добавить пустой туннель» — программа сама создаст пару ключей и подставит приватный ключ в поле конфига, а публичный ключ покажет отдельной строкой сверху окна. Этот публичный ключ и нужно передать администратору сервера или второй стороне туннеля.

Для нескольких серверов удобнее генерировать ключи из PowerShell, не открывая каждый раз GUI. Классической утилиты wg.exe в графическом инсталляторе нет — WireGuard для Windows управляется приложением и самим wireguard.exe с параметрами командной строки. Для генерации через консоль используйте кроссплатформенную сборку wireguard-tools, которую разработчик публикует отдельно от GUI: распакуйте архив, добавьте путь к wg.exe в PATH — и команды работают так же, как в Linux-гайдах.

# генерация приватного и публичного ключей сервера
wg genkey | Tee-Object -FilePath server_private.key | wg pubkey | Tee-Object -FilePath server_public.key

# генерация пары для клиента (например, рабочей станции админа)
wg genkey | Tee-Object -FilePath client_private.key | wg pubkey | Tee-Object -FilePath client_public.key

Логика та же, что и на Linux: приватный ключ никогда не покидает своё устройство, в конфиг другой стороны вписывается только публичный. Каждому новому устройству — своя пара ключей и свой внутренний адрес; переиспользовать одну пару на двух машинах нельзя, туннель будет рваться из-за конфликта пиров.

Создание конфига туннеля

Файл туннеля в Windows-клиенте — обычный .conf-файл в том же формате, что и на Linux, разница только в способе загрузки: через GUI кнопкой «Импорт», а не wg-quick. На стороне Windows Server конфиг выглядит так:

[Interface]
PrivateKey = <PRIVATE_KEY_СЕРВЕРА>
Address = 10.20.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <PUBLIC_KEY_КЛИЕНТА>
AllowedIPs = 10.20.0.2/32

Address — внутренний адрес сервера в туннельной подсети, ListenPort — UDP-порт, на котором сервер ждёт подключения (дефолтный 51820 можно сменить на любой другой). Блок [Peer] описывает клиента: его публичный ключ и выделенный адрес внутри туннеля.

Конфиг клиента (рабочей станции админа или ноутбука сотрудника) компактнее:

[Interface]
PrivateKey = <PRIVATE_KEY_КЛИЕНТА>
Address = 10.20.0.2/32

[Peer]
PublicKey = <PUBLIC_KEY_СЕРВЕРА>
Endpoint = <ПУБЛИЧНЫЙ_IP_СЕРВЕРА>:51820
AllowedIPs = 10.20.0.0/24
PersistentKeepalive = 25

AllowedIPs = 10.20.0.0/24 направляет через туннель только трафик к серверу и соседним машинам в подсети — сам туннель не забирает весь интернет-трафик клиента, что удобно для доступа к рабочим ресурсам. PersistentKeepalive = 25 держит соединение живым, если клиент сидит за NAT. Сохраните файл с расширением .conf и импортируйте его в приложение через «Импорт туннеля(-ей) из файла».

Генерацию ключей и конфигов на Linux-стороне (например, для второго сервера в связке) мы разбирали по шагам в статье про установку и настройку WireGuard на VPS.

Настройка автозапуска как службы Windows

Ключевое отличие Windows-клиента от Linux: при активации туннеля через GUI WireGuard сам создаёт для него отдельную службу Windows с именем WireGuardTunnel

# генерация приватного и публичного ключей сервера
wg genkey | Tee-Object -FilePath server_private.key | wg pubkey | Tee-Object -FilePath server_public.key

# генерация пары для клиента (например, рабочей станции админа)
wg genkey | Tee-Object -FilePath client_private.key | wg pubkey | Tee-Object -FilePath client_public.key

[Interface]
PrivateKey = <PRIVATE_KEY_СЕРВЕРА>
Address = 10.20.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <PUBLIC_KEY_КЛИЕНТА>
AllowedIPs = 10.20.0.2/32

[Interface]
PrivateKey = <PRIVATE_KEY_КЛИЕНТА>
Address = 10.20.0.2/32

[Peer]
PublicKey = <PUBLIC_KEY_СЕРВЕРА>
Endpoint = <ПУБЛИЧНЫЙ_IP_СЕРВЕРА>:51820
AllowedIPs = 10.20.0.0/24
PersistentKeepalive = 25

Get-Service -Name "WireGuardTunnel*"
Set-Service -Name "WireGuardTunnel$server" -StartupType Automatic

wireguard.exe /installtunnelservice C:\wireguard\server.conf

wireguard.exe /uninstalltunnelservice server

# разрешить входящий UDP-трафик WireGuard из интернета
New-NetFirewallRule -DisplayName "WireGuard UDP 51820" `
  -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

# разрешить RDP только из туннельной подсети 10.20.0.0/24
New-NetFirewallRule -DisplayName "RDP только через WireGuard" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress 10.20.0.0/24 -Action Allow

# отключить штатное правило RDP, которое разрешает подключение с любого адреса
Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
  Where-Object {$_.Direction -eq "Inbound"} |
  Disable-NetFirewallRule

Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*WireGuard*"}
Test-Connection 10.20.0.1 -Count 4

lt;имя_туннеля> и включает автозапуск. После перезагрузки сервера туннель поднимется сам, ещё до входа администратора по RDP — что и требуется, если сама возможность зайти по RDP зависит от поднятого туннеля.

Чтобы это сработало, туннель нужно один раз активировать вручную: откройте WireGuard, выберите импортированный туннель и нажмите «Активировать» — с этого момента служба зарегистрирована и стартует автоматически. Проверить и поправить тип запуска можно через services.msc либо из PowerShell:

Get-Service -Name "WireGuardTunnel*"
Set-Service -Name "WireGuardTunnel$server" -StartupType Automatic

Для Server Core или массового развёртывания служба ставится напрямую из командной строки, без открытия GUI:

wireguard.exe /installtunnelservice C:\wireguard\server.conf

Удаляется служба туннеля аналогично:

wireguard.exe /uninstalltunnelservice server

Обратите внимание: конфиг-файл после установки службы копируется во внутреннее хранилище WireGuard, поэтому исходный .conf стоит удалить с диска или ограничить к нему доступ — приватный ключ в нём хранится в открытом виде.

Настройка правил Windows Firewall

Смысл всей схемы теряется, если снаружи по-прежнему доступен и туннель, и голый RDP. Правило простое: наружу открыт только UDP-порт WireGuard, TCP-порт 3389 разрешён исключительно из туннельной подсети, остальное входящее — закрыто. Настраивается через New-NetFirewallRule в PowerShell от имени администратора:

# разрешить входящий UDP-трафик WireGuard из интернета
New-NetFirewallRule -DisplayName "WireGuard UDP 51820" `
  -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

# разрешить RDP только из туннельной подсети 10.20.0.0/24
New-NetFirewallRule -DisplayName "RDP только через WireGuard" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress 10.20.0.0/24 -Action Allow

# отключить штатное правило RDP, которое разрешает подключение с любого адреса
Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
  Where-Object {$_.Direction -eq "Inbound"} |
  Disable-NetFirewallRule

Порядок важен: сначала создаётся новое правило со scope-ограничением по адресу туннельной подсети, и только потом отключается стандартная группа правил «Remote Desktop», которая по умолчанию пускает RDP с любого IP. Проверяйте оба правила до отключения текущей RDP-сессии, а лучше держите под рукой доступ через консоль провайдера сервера на случай ошибки.

Для сценария офисного шлюза (доступ не только к RDP, а к нескольким внутренним сервисам) логика та же: каждое правило firewall для внутреннего порта получает -RemoteAddress с туннельной подсетью, а не «любой адрес». Порт WireGuard остаётся единственным, что видно снаружи.

Проверка соединения и типичные проблемы

После активации туннеля с обеих сторон в GUI появляются счётчики переданных и принятых данных, а строка «Последнее рукопожатие» обновляется каждые пару минут — это главный признак живого туннеля. Проверить адаптер и маршрут из PowerShell:

Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*WireGuard*"}
Test-Connection 10.20.0.1 -Count 4

Если пинг по туннельному адресу проходит, а mstsc /v:10.20.0.1 открывает окно ввода пароля — всё настроено верно.

Типичные проблемы:

• Служба туннеля не стартует. Чаще всего конфликт порта или повреждённый конфиг при импорте. Проверьте статус через Get-Service -Name "WireGuardTunnel*", детали смотрите в Event Viewer → Applications and Services Logs.
• Нет прав администратора. Установка клиента, регистрация службы и правила firewall требуют повышенных прав — от обычного пользователя операции молча завершатся ошибкой доступа.
• Конфликт с уже включённым VPN-клиентом Windows. Штатный или корпоративный VPN может забрать таблицу маршрутизации, особенно если его маршруты пересекаются с AllowedIPs. Отключите второй VPN и проверьте route print — один диапазон через два адаптера даёт непредсказуемый трафик.

Похожий разбор ошибок со стороны Linux-сервера есть в статье про частые проблемы WireGuard на сервере — пригодится, если туннель идёт между Windows-клиентом и Linux-сервером.

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