VPN для удалённой команды: типовая схема на 10-20 сотрудников

MAATRIX

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

Сколько ресурсов нужно серверу

Для 10-20 одновременных подключений VPN сам по себе не требователен к CPU и RAM — узкое место почти всегда сеть, а не вычисления.

Ориентир для планирования (это именно ориентир, а не гарантированные цифры — реальная нагрузка зависит от того, чем занимается команда: текстовая переписка и доступ к внутренним сервисам — это одно, постоянные видеозвонки и передача больших файлов через VPN — совсем другое):

WireGuard шифрует в разы легче, чем OpenVPN на TLS, и на 1-2 ядрах современного процессора спокойно тянет несколько сотен Мбит/с суммарного трафика 20 клиентов — упереться в CPU на таком масштабе почти нереально. OpenVPN с шифрованием AES-256-GCM тоже справится, но при активном использовании (постоянные видеозвонки, RDP-сессии) стоит закладывать на одно ядро больше про запас.

Реальный лимит — не мощность сервера, а канал и то, сколько трафика команда гонит через VPN. Если через сервер идёт весь интернет-трафик 20 человек (full-tunnel), а не только доступ к внутренним ресурсам (split-tunnel), канал в 100 Mbps может оказаться узким местом уже при паре одновременных видеозвонков в HD. Практический вывод: начинайте с 2 vCPU / 2 GB RAM / SSD-диска на VPS, канал берите с запасом от заявленной пропускной способности провайдера, а split-tunnel настраивайте по умолчанию — через сервер пускайте только то, что действительно требует защищённого доступа (внутренние сервисы, базы, админки), а не весь трафик команды на YouTube.

Какой протокол проще администрировать на 10-20 человек

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

WireGuard выигрывает по административной простоте: конфиг клиента — это пара строк (приватный ключ, публичный ключ сервера, IP), файл сервера — плоский список пиров. Добавить сотрудника — сгенерировать пару ключей и дописать блок [Peer]. Никакого центра сертификации, никаких сроков действия, которые надо отслеживать. Минус — нет встроенного отзыва «на лету» без перезапуска интерфейса и нет built-in клиента с логином/паролем: это чистая криптография поверх UDP, аутентификация — только по ключу.

OpenVPN даёт больше контроля за счёт PKI (сертификаты через Easy-RSA): можно отозвать доступ конкретному сотруднику через CRL, не трогая остальных, можно комбинировать сертификат с логином/паролем (двухфакторность на уровне подключения), можно раздавать разные права разным группам через client-config-dir. Плата за это — сложнее разворачивать с нуля и медленнее работает на слабом железе из-за TLS-хендшейка и накладных расходов OpenSSL.

Для команды 10-20 человек, где состав меняется (кто-то увольняется, приходят новые) и важна централизованная политика доступа, разумный выбор — либо WireGuard с панелью управления поверх (закрывает минус с ключами), либо OpenVPN, если у компании уже есть требования по сертификатам или комплаенсу. Если сомневаетесь, начните с WireGuard — миграция с него на OpenVPN при росте требований проще, чем наоборот. Подробное сравнение протоколов по сценариям — в статье WireGuard или OpenVPN: что выбрать для сервера.

Топология: один сервер-хаб, а не мешанина туннелей

Для 10-20 человек не нужен mesh (каждый с каждым) — это оправдано для распределённой инфраструктуры из нескольких офисов и серверов, но избыточно для доступа удалённых сотрудников к общим ресурсам. Стандартная и предсказуемая схема — «звезда»: один VPN-сервер в центре, все клиенты подключаются к нему, сервер маршрутизирует трафик к внутренним ресурсам (или в интернет, если нужен full-tunnel).

Базовая адресация для WireGuard на 20 клиентов:

# сервер
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key>

# клиенты получают 10.10.0.2 - 10.10.0.21

Если у команды есть внутренние сервисы (Git-сервер, база, панель мониторинга) на отдельной машине или в отдельной подсети, добавьте маршрут через AllowedIPs только к нужной подсети — это и есть split-tunnel на уровне конфига:

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.10.0.5/32, 192.168.50.0/24

Такая схема легко читается через полгода, когда придётся разбираться, кто и куда имеет доступ — в отличие от ручных правил маршрутизации, которые обычно накапливаются хаотично.

Управление доступом: сертификаты или ключи, но с процессом

Технология вторична — первична дисциплина процесса. На 3 пользователях можно держать всё в голове, на 20 — нельзя.

Минимальный процесс, который работает в обе стороны (OpenVPN и WireGuard):

• Один клиентский конфиг = один сотрудник. Никаких общих конфигов «на отдел» — тогда отзыв доступа при увольнении не требует перевыпуска всем.
• Именование по сотруднику, не по устройству: ivanov-laptop, ivanov-phone — сразу видно, кому что принадлежит, если у людей по 2 устройства.
• Реестр выданных доступов — таблица (даже простой файл в репозитории с ограниченным доступом): кому, когда, с какого устройства, кто выдал. Без этого через полгода никто не вспомнит, зачем в конфиге висит guest-temp.
• Регламент отзыва — при увольнении/уходе в отпуск на длительный срок доступ отзывается в тот же день, а не «когда руки дойдут».

Для OpenVPN отзыв — это добавление сертификата в CRL и crl-verify в конфиге сервера:

cd /etc/openvpn/easy-rsa
./easyrsa revoke ivanov-laptop
./easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/crl.pem
systemctl restart openvpn@server

Подробная настройка сертификатов на несколько пользователей через Easy-RSA — в статье OpenVPN: сертификаты для нескольких пользователей через Easy-RSA.

Для WireGuard отзыв проще технически, но требует ручного шага: удалить блок [Peer] соответствующего ключа из конфига сервера и перезагрузить интерфейс (wg syncconf — без разрыва остальных сессий):

wg set wg0 peer <public_key> remove
wg-quick strip wg0 > /etc/wireguard/wg0.conf

Панель управления вместо ручных правок конфига

На 20 пользователях редактировать конфиг руками через SSH каждый раз, когда кто-то приходит или уходит, — источник ошибок (забытая запятая, не тот IP, конфликт адресов). Веб-панель поверх WireGuard снимает эту рутину и даёт визуальный список активных пиров с датой последнего подключения — удобно для того самого реестра доступов.

Практичный вариант — wg-easy: разворачивается одним Docker-контейнером, даёт веб-интерфейс для добавления/удаления клиентов и генерирует QR-код для мобильных устройств:

docker run -d \
  --name wg-easy \
  -e WG_HOST=<ip_или_домен_сервера> \
  -e PASSWORD=<пароль_панели> \
  -v ~/.wg-easy:/etc/wireguard \
  -p 51820:51820/udp \
  -p 51821:51821/tcp \
  --cap-add=NET_ADMIN \
  --cap-add=SYS_MODULE \
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
  --restart unless-stopped \
  ghcr.io/wg-easy/wg-easy

Подробный разбор установки и настройки — в статье wg-easy: веб-панель для WireGuard. Для команд, которым нужно раздавать доступ без выдачи root-прав на сервер (например, HR или тимлид добавляет новых сотрудников самостоятельно), стоит посмотреть на разграничение ролей — об этом отдельно в статье как раздать доступ команде без выдачи root.

Минус панелей — ещё один сервис, который надо обновлять и который открывает дополнительный порт наружу. Держите админ-панель либо за отдельным firewall-правилом (доступ только с определённых IP), либо саму — только через уже поднятый VPN-туннель, а не в открытом интернете.

Резервирование и мониторинг на масштабе команды

Для 2-3 пользователей падение VPN-сервера — неприятность, которую решают за час. Для команды из 20 человек, работающей полностью удалённо, это простой в работе всей компании, и об этом стоит подумать заранее, а не после первого инцидента.

Минимальный набор мер без избыточного усложнения:

• Мониторинг доступности — простой скрипт по cron, который раз в 5 минут проверяет отклик на порт VPN и присылает уведомление, если сервер недоступен. Разворачивать полноценный Zabbix/Prometheus на такой масштаб обычно избыточно, если инфраструктура этим одним сервером и ограничивается.
• Регулярный бэкап конфигов — /etc/wireguard или /etc/openvpn вместе с ключами клиентов. Восстановление после потери сервера должно занимать минуты, а не повторную выдачу 20 конфигов вручную.
• Резервный сервер (опционально) — вторая VPS в режиме холодного резерва с теми же конфигами, на которую можно быстро переключить DNS-запись или раздать клиентам обновлённый endpoint при аварии основного. Оправдано, если простой VPN действительно останавливает работу команды (а не просто неудобство на пару часов).

Детали настройки автопереключения на резервный сервер и мониторинга активных подключений — в статьях резервный VPN-сервер: автопереключение и мониторинг VPN-подключений на Windows Server (принцип мониторинга переносится и на Linux-сервер).

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