Туннель на семью или офис через Windows Server

MAATRIX

Когда VPN нужен не вам одному, а всей семье или небольшому офису, личный аккаунт в коммерческом сервисе быстро упирается в лимит устройств и общий пароль на всех. Свой Windows Server с WireGuard снимает это ограничение: каждый человек получает отдельный конфиг и ключевую пару, вы в любой момент видите, кто подключён, и можете отключить одного человека, не трогая остальных. Ниже — рабочая схема на 5-20 клиентов с генерацией конфигов, управлением доступом и выбором между общим выходом в интернet и разделением клиентов на изолированные подсети.

Почему один сервер, а не VPN-подписка на каждого

Готовые VPN-сервисы продают доступ по подписке на 1-5 устройств, и как только в семье или офисе больше пяти человек, вы либо покупаете несколько аккаунтов, либо все сидят под одним логином — а тогда отключить одного человека можно только сменой пароля для всех сразу. Свой сервер решает это иначе: WireGuard не различает "пользователей" — он различает ключи. У каждого члена семьи или сотрудника своя пара ключей и свой блок [Peer] в конфиге сервера, поэтому один аккаунт никогда не пересекается с другим физически.

Экономика тоже меняется в вашу пользу: аренда Windows-сервера стоит примерно как один VPN-тариф среднего уровня, а трафик и число подключений не тарифицируются по головам. При этом вы получаете полный контроль над логами, скоростью и локацией выхода — сервер стоит там, где нужно вам (Россия, США или Великобритания), а не там, где решил провайдер VPN.

Из минусов — обслуживание на вас: обновления, бэкапы конфигов и объяснение родственникам, как поставить приложение WireGuard на телефон. Для 5-20 клиентов это разовая настройка на пару часов и потом 10 минут в месяц на добавление или отключение человека.

Архитектура: один интерфейс, одна подсеть, много пиров

WireGuard на сервере работает как один сетевой интерфейс (обычно называется wg0), у которого есть внутренний IP, например 10.20.0.1/24. Каждый клиент — это не отдельный туннель, а запись [Peer] в конфиге этого единственного интерфейса, со своим публичным ключом и своим внутренним адресом из той же подсети (10.20.0.2, 10.20.0.3 и так далее). Именно поэтому масштабирование до 10-20 клиентов не требует новых интерфейсов или портов — один сервис wireguard-nt на сервере обслуживает всех сразу.

Схема на файловой системе Windows Server выглядит так:

C:\WireGuard\
  server_public.key
  server_private.key
  wg0.conf                  # конфиг сервера со всеми [Peer]
  clients\
    papa.conf
    mama.conf
    syn.conf
    office-laptop-01.conf
    office-laptop-02.conf

Базовый конфиг сервера (wg0.conf) до добавления клиентов:

[Interface]
PrivateKey = <приватный_ключ_сервера>
Address = 10.20.0.1/24
ListenPort = 51820

Держите папку clients\ рядом с конфигом сервера — это единственное место, где физически хранятся приватные ключи всех участников, и её обязательно нужно включить в бэкап сервера отдельно от системного диска.

Генерация ключей и конфига для каждого клиента

Официальный установщик WireGuard для Windows кладёт консольный wg.exe рядом с GUI-приложением, обычно в C:\Program Files\WireGuard\. Через него удобно штамповать ключи скриптом, не открывая GUI на каждого человека вручную.

PowerShell-скрипт добавления одного клиента (сохраните как add-client.ps1):

param(
    [Parameter(Mandatory=$true)][string]$Name,
    [Parameter(Mandatory=$true)][int]$LastOctet,   # 2, 3, 4 ...
    [string]$ServerEndpoint = "203.0.113.10:51820",
    [string]$ServerPubKey = (Get-Content "C:\WireGuard\server_public.key")
)

$wg = "C:\Program Files\WireGuard\wg.exe"
$priv = & $wg genkey
$pub  = $priv | & $wg pubkey
$clientIp = "10.20.0.$LastOctet/32"

# конфиг для клиента
@"
[Interface]
PrivateKey = $priv
Address = 10.20.0.$LastOctet/24
DNS = 1.1.1.1

[Peer]
PublicKey = $ServerPubKey
Endpoint = $ServerEndpoint
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
"@ | Out-File "C:\WireGuard\clients\$Name.conf" -Encoding ascii

# блок для добавления на сервер
@"

[Peer]
# $Name
PublicKey = $pub
AllowedIPs = $clientIp
"@ | Out-File "C:\WireGuard\wg0.conf" -Encoding ascii -Append

Write-Host "Клиент $Name добавлен, IP 10.20.0.$LastOctet, конфиг в clients\$Name.conf"

Запуск на каждого нового человека:

.\add-client.ps1 -Name "papa" -LastOctet 2
.\add-client.ps1 -Name "mama" -LastOctet 3
.\add-client.ps1 -Name "syn" -LastOctet 4

Готовый clients\papa.conf отдаёте человеку — он либо сканирует QR-код (сгенерируйте его через qrencode или онлайн-конвертер конфига в QR прямо на сервере, не пересылая файл через сторонние сервисы), либо импортирует файл в приложение WireGuard на телефоне или ноутбуке напрямую.

После добавления блоков в wg0.conf применяете конфиг без пересоздания службы:

& "C:\Program Files\WireGuard\wg.exe" syncconf wg0 "C:\WireGuard\wg0.conf"

Если syncconf в вашей сборке недоступен, надёжный запасной вариант — перезапуск конкретной службы туннеля:

Restart-Service "WireGuardTunnel$wg0"

Разрыв при этом длится 1-3 секунды и задевает всех клиентов сразу — для семьи это некритично, но офис лучше предупреждать заранее или переключаться на syncconf, который применяет изменения на лету.

Управление доступом: отключить одного человека одним движением

Смысл отдельного ключа на каждого именно в том, что отзыв доступа — это удаление одного блока [Peer], а не смена общего пароля. Посмотреть, кто сейчас подключён и когда был последний handshake:

& "C:\Program Files\WireGuard\wg.exe" show wg0

Вывод покажет публичный ключ, IP и latest handshake для каждого пира — по этому списку легко сопоставить активность с именами из ваших файлов в clients\, если вести рядом простую таблицу "имя → публичный ключ".

Чтобы отключить конкретного человека, найдите его блок в wg0.conf по комментарию с именем, удалите весь блок [Peer] и снова примените конфиг:

& "C:\Program Files\WireGuard\wg.exe" syncconf wg0 "C:\WireGuard\wg0.conf"

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

Для офиса имеет смысл вести учёт построже — таблицу или простой CSV-файл со столбцами "имя, дата выдачи, устройство, публичный ключ", и раз в квартал сверять её со списком в wg show wg0, отключая записи для уволенных сотрудников или сданных устройств.

Масштабирование до 10-20 клиентов на одном сервере

WireGuard в ядре Windows (wireguard-nt) обрабатывает десятки пиров без заметной нагрузки на CPU — узкое место на практике не в числе клиентов, а в суммарной пропускной способности канала сервера и в свободных адресах подсети. Подсеть /24 (например 10.20.0.0/24) даёт больше 250 адресов, этого хватит с большим запасом.

Что стоит учитывать при росте числа клиентов:

Практический ориентир: для базового домашнего трафика (браузинг, мессенджеры, изредка видео) один средний по конфигурации Windows-сервер спокойно тянет 15-20 одновременных клиентов. Если часть людей смотрит стриминг в 4K одновременно — закладывайте канал с запасом, точную цифру даст только тест на вашем реальном тарифе у хостера.

Для удобства управления при таком числе клиентов замените ручной запуск скрипта на CSV-файл со списком имён и последовательным перебором LastOctet, чтобы не путаться в занятых адресах — простой цикл foreach в PowerShell по строкам CSV решает это за несколько минут.

Общий выход в интернет или отдельная подсеть на каждого

Здесь два разных сценария, и их стоит разделять осознанно.

Общий выход (все выходят в интернет с одного IP сервера). Все клиенты пишут AllowedIPs = 0.0.0.0/0 в своём конфиге и получают NAT на внешний интерфейс сервера. Это классический "все смотрят в мир одним лицом" — подходит для семьи, где важно единое место выхода (например, для доступа к сервисам одной страны) и не важна изоляция между устройствами друг от друга. Требует включённого IP-форвардинга и NAT на сервере:

# включить форвардинг
Set-NetIPInterface -InterfaceAlias "wg0" -Forwarding Enabled

# NAT через роль RRAS (Routing and Remote Access)
Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools
Install-RemoteAccess -VpnType RoutingOnly
netsh routing ip nat install
netsh routing ip nat add interface "Ethernet"    # внешний интерфейс
netsh routing ip nat set interface "Ethernet" mode=full

Изоляция клиентов друг от друга. Общая подсеть 10.20.0.0/24 по умолчанию не мешает клиентам видеть друг друга внутри туннеля — WireGuard сам по себе не разграничивает пиров между собой, это забота маршрутизации и файрвола. Если в офисе не должно быть, чтобы ноутбук стажёра видел сервер бухгалтерии в том же VPN, добавьте блокирующее правило на интерфейсе wg0:

New-NetFirewallRule -DisplayName "WG-Block-Client-to-Client" `
  -Direction Inbound -InterfaceAlias "wg0" `
  -RemoteAddress 10.20.0.0/24 -Action Block `
  -Protocol Any

# и точечно разрешить то, что нужно (например, доступ к общему серверу 10.20.0.1)
New-NetFirewallRule -DisplayName "WG-Allow-To-Gateway" `
  -Direction Inbound -InterfaceAlias "wg0" `
  -RemoteAddress 10.20.0.1/32 -Action Allow -Protocol Any

Порядок применения правил в Windows Defender Firewall важен — более специфичное разрешающее правило должно иметь приоритет выше общего блокирующего, иначе разрешение не сработает. Для семьи изоляция обычно не нужна (наоборот, полезно видеть друг друга для расшаренной папки или принтера), а для офиса — почти всегда обязательна.

Про настройку самого файрвола Windows под туннель подробнее в статье про фаервол на Windows Server для туннеля, а базовая установка WireGuard на Windows Server описана в отдельном пошаговом материале.

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