VPN для администраторов игрового сервера

MAATRIX GAMES

Сервер администрирует не один человек, а трое-пятеро: кто-то работает из дома с динамическим IP от домашнего провайдера, кто-то из другого города, кто-то вообще подключается с ноутбука в кафе через мобильный интернет. Ограничить SSH и RCON по IP-адресу — это правильно и отдельно разобрано в статье про настройку файрвола, но для команды с разными и меняющимися адресами это превращается в постоянную возню: каждый раз, когда у кого-то сменился провайдер или он уехал в другой город, приходится лезть в правила ufw и добавлять новый IP. VPN решает это иначе — вместо списка внешних адресов у команды появляется одна внутренняя сеть, и именно в ней уже прописываются разрешения.

Какую проблему на самом деле решает VPN

Правило "разрешён доступ только с конкретного IP" отлично работает, когда админ один и подключается из одного места. Проблема начинается, когда админов несколько и у каждого свои условия подключения. Варианта тут по факту три, и все с недостатками:

• Открыть SSH/RCON всему интернету. Просто, но плохо — порт тут же начинает получать перебор паролей от ботов, которые сканируют диапазоны IP круглосуточно.
• Вносить IP каждого админа в белый список файрвола. Работает, пока IP статический. У домашнего интернета в России IP чаще всего динамический — провайдер может поменять его после перезагрузки роутера или планового обслуживания, и админ внезапно теряет доступ, а разбираться с этим приходится в панике посреди инцидента на сервере.
• VPN. Каждый участник команды подключается к общей приватной сети и получает в ней постоянный внутренний IP независимо от того, откуда он физически заходит в интернет. Файрвол на сервере разрешает SSH и RCON только для этой внутренней подсети — и больше вообще не важно, какой у админа "внешний" адрес сегодня.

По сути VPN здесь — это способ превратить "разных людей с разных нестабильных адресов" в "одну предсказуемую подсеть", с которой и работает файрвол.

WireGuard: почему именно он

Из VPN-протоколов для этой задачи разумно смотреть в сторону WireGuard — он появился позже OpenVPN и IPsec, устроен заметно проще (кодовая база на порядки меньше), быстрее поднимается по производительности и не требует тяжёлой настройки сертификатов. Конфиг сервера и клиента — это буквально несколько строк с парой ключей, а не связка файлов сертификатов, которую легко перепутать.

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

Общая логика настройки на Linux-сервере (Ubuntu/Debian) выглядит так:

sudo apt update && sudo apt install wireguard

# генерируем ключи сервера
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key

Дальше в /etc/wireguard/wg0.conf описывается сама сеть — например, подсеть 10.10.0.0/24, где сервер получает адрес 10.10.0.1, а каждый админ — следующий свободный (10.10.0.2, 10.10.0.3 и так далее):

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

[Peer]
# админ 1
PublicKey = <публичный_ключ_админа_1>
AllowedIPs = 10.10.0.2/32

[Peer]
# админ 2
PublicKey = <публичный_ключ_админа_2>
AllowedIPs = 10.10.0.3/32

У каждого админа на своей машине — зеркальный конфиг клиента, где Endpoint указывает на публичный IP игрового сервера и порт WireGuard (обычно UDP/51820, его тоже нужно открыть в файрволе — но только его, широко и без ограничений, поскольку сама аутентификация идёт по ключам). Это общие принципы, чтобы понимать логику — если нужна пошаговая инструкция с генерацией конфигов для клиентов и деталями роутинга, таких мануалов по WireGuard в сети достаточно, и лучше свериться с актуальной документацией под вашу ОС, поскольку мелкие детали (systemd-юниты, автозапуск) отличаются между дистрибутивами.

Что даёт VPN-подсеть и почему это удобнее статичного IP

После того как WireGuard поднят и все админы подключены, у команды появляется постоянная внутренняя подсеть — в примере выше это 10.10.0.0/24. Дальше правила файрвола на игровом сервере переписываются так, чтобы разрешать чувствительные сервисы не с конкретных внешних IP, а с этой подсети целиком:

sudo ufw allow from 10.10.0.0/24 to any port 22 proto tcp
sudo ufw allow from 10.10.0.0/24 to any port 28016 proto tcp

Плюс такого подхода: когда в команде появляется новый админ или кто-то уезжает в командировку и подключается из другой страны — ничего не меняется на стороне файрвола сервера. Меняется только конфиг WireGuard (добавляется/убирается peer), а правила доступа остаются теми же, потому что они завязаны на внутренний VPN-адрес, а не на физическое местоположение человека.

Ограничиваем SSH, RCON и панель управления только VPN-подсетью

Смысл всей затеи — не просто поднять VPN, а реально закрыть публичный доступ к тому, что не должно торчать в открытый интернет. Три типичные точки, которые стоит спрятать за VPN:

• SSH — доступ к самой машине. Если хостер даёт возможность сменить порт SSH с 22 на нестандартный, это дополнительная мера, но не замена ограничения по подсети.
• RCON — про сам протокол и команды подробно в статье про RCON-подключение. RCON-пароль — это фактически ключ от консоли сервера, и светить порт RCON в открытый интернет даже с паролем — риск на подбор или утечку.
• Панель управления (если используется что-то вроде Pterodactyl, AMP или веб-интерфейса хостинга с отдельным портом) — тоже логично прятать за VPN, если панель не защищена собственной сложной аутентификацией и не обязана быть доступна извне.

После настройки WireGuard правило простое: любой порт, который нужен только команде админов (не игрокам), закрывается для всего интернета и открывается исключительно для VPN-подсети. Игровой порт (тот, к которому подключаются игроки) при этом, разумеется, остаётся открытым всем — VPN не имеет отношения к доступу игроков на сервер, это исключительно про административные каналы.

Роли внутри VPN и права на сервере — разные вещи

Стоит держать в голове: VPN даёт сетевой доступ ("этот человек физически может достучаться до SSH/RCON"), но не разграничивает, что именно человек может делать внутри. Если у команды есть модераторы, которым не нужен полный shell-доступ, а нужны только команды бана и кика — это уже вопрос ролей и прав внутри самой панели или RCON, а не VPN. Подробно про то, как разграничить роли между старшим админом, обычным админом и модератором, разобрано в статье про права доступа и роли администраторов. VPN здесь — только первый рубеж, "может ли этот компьютер вообще постучаться в дверь", а не "что ему разрешено делать после того как постучался".

Альтернативы и когда VPN явно избыточен

Если вы администрируете сервер в одиночку, ставить WireGuard ради одного человека почти всегда не имеет смысла — статический IP или динамический DNS (когда провайдер меняет IP, но домен всегда указывает на актуальный адрес) закроют задачу проще и без лишней инфраструктуры, которую потом тоже нужно поддерживать: обновлять список ключей, следить, чтобы конфиг клиента не потерялся вместе с ноутбуком. VPN оправдан ровно там, где есть команда: несколько человек с разными и не всегда предсказуемыми точками подключения, которым нужен общий рубеж доступа. Если у вас статичный домашний IP и вы админите один — просто впишите этот один адрес в правило ufw, как описано в статье про файрвол, и не усложняйте.

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

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