Как настроить WireGuard VPN для удалённых сотрудников
Практика3 минРедакция Innovialabs
Коротко
Поднимите WireGuard на роутере, VPS или офисном сервере, выдайте каждому устройству свою пару ключей и отдельный IP, в AllowedIPs укажите только офисные подсети, а при увольнении удалите peer с сервера.
Коротко о схеме
WireGuard — простой и быстрый VPN-протокол. В нём нет логинов и паролей: каждое устройство имеет пару ключей, а сервер знает публичные ключи разрешённых клиентов. Кто владеет приватным ключом — тот и подключается.
Отсюда главные правила:
- один ключ — одно устройство, никаких общих конфигов на отдел;
- каждый клиент получает свой IP внутри VPN;
- у вас есть список, где записано, какой ключ кому принадлежит.
Шаг 1. Где запустить сервер
| Вариант | Плюсы | Минусы |
|---|---|---|
| Роутер с поддержкой WireGuard | Без отдельного железа, прямой доступ к офисной сети | Нужен белый IP или DDNS, нагрузка на роутер |
| VPS в облаке | Статический IP, офис не открывает порты | Офис нужно связать с VPS отдельным туннелем |
| Офисный сервер или мини-ПК | Гибкость, мощность | Проброс порта на роутере, настройка маршрутизации |
Для небольшого офиса с белым IP проще всего роутер. Если белого IP нет — VPS, к которому подключаются и сотрудники, и офисный роутер.
Порт WireGuard работает по UDP. Его нужно открыть на сервере и, при необходимости, пробросить на роутере.
Шаг 2. Сгенерируйте ключи
На Linux ключи создаются утилитой wg:
umask 077
wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee alice-laptop.key | wg pubkey > alice-laptop.pub
Приватные ключи (.key) никогда не пересылайте открытым текстом в мессенджерах. Многие клиентские приложения умеют сами генерировать ключ на устройстве — тогда приватный ключ вообще не покидает ноутбук, а вам передают только публичный.
Шаг 3. Конфигурация сервера
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <содержимое server.key>
[Peer]
# alice-laptop
PublicKey = <содержимое alice-laptop.pub>
AllowedIPs = 10.8.0.2/32
На сервере AllowedIPs — это адрес, который разрешено использовать клиенту. Если сервер — не роутер, а отдельная машина, включите на ней IP forwarding и настройте маршрут или NAT в офисную сеть.
Шаг 4. Конфигурация клиента
[Interface]
PrivateKey = <ключ устройства>
Address = 10.8.0.2/32
DNS = 192.168.1.1
[Peer]
PublicKey = <содержимое server.pub>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25
Здесь 192.168.1.0/24 — пример офисной подсети, подставьте свою. PersistentKeepalive помогает держать туннель живым за NAT. Конфиг для телефона удобно передать QR-кодом.
Шаг 5. Split или full tunnel
Это решается одной строкой AllowedIPs в конфиге клиента:
- Split tunnel —
AllowedIPs = 10.8.0.0/24, 192.168.1.0/24. Через VPN идёт только трафик в офис, остальной интернет — напрямую. Меньше нагрузка на офисный канал. - Full tunnel —
AllowedIPs = 0.0.0.0/0, ::/0. Весь трафик идёт через офис. Нужен, если доступ к сервисам разрешён только с офисного IP или требуется фильтрация трафика.
Для большинства офисов достаточно split tunnel.
Шаг 6. Отзыв доступа
Когда сотрудник увольняется или теряет ноутбук:
- Удалите peer из работающего интерфейса:
wg set wg0 peer <публичный ключ> remove
- Удалите блок
[Peer]из конфигурационного файла, чтобы он не вернулся после перезапуска. - Отметьте в реестре ключей дату отзыва.
- Проверьте, нет ли у этого человека других устройств с ключами.
Если не вести реестр, через год уже никто не скажет, кому принадлежит peer без комментария.
Частые ошибки
- Один конфиг на несколько человек — отозвать доступ одному невозможно.
- Full tunnel без необходимости — офисный канал перегружен чужим трафиком.
- Совпадение офисной подсети с домашней сетью сотрудника (например, обе
192.168.1.0/24) — маршрутизация ломается. Используйте для офиса менее типичную подсеть. - Пересылка приватных ключей в общих чатах.