Права владельца vs права арендатора VPS — что можно и нельзя менять

MAATRIX GAMES

Рано или поздно каждый, кто арендует VPS под игровой сервер, натыкается на стену: apt install не ставит нужный модуль ядра, sysctl ругается на "operation not permitted", а тикет в поддержку хостера отвечает "это на стороне гипервизора, недоступно клиенту". И тут возникает вопрос — а что вообще моё на этой машине, а что нет? Разложим по полочкам, где заканчиваются права арендатора и начинается зона ответственности провайдера, и что с этим делать на практике.

Что такое VPS с точки зрения прав, а не маркетинга

VPS (Virtual Private Server) — это не отдельный физический сервер, а нарезанный кусок общего "железа" под управлением гипервизора. Гипервизор — это низкоуровневый софт (обычно KVM, реже Xen или проприетарные решения), который живёт на хост-машине и раздаёт виртуальным машинам куски CPU, RAM, диска и сети. У арендатора нет и не может быть доступа к этому слою — это как арендовать квартиру в доме и требовать доступ к щитку на весь подъезд.

Дальше есть два принципиально разных типа виртуализации, и от этого зависит, сколько прав у тебя реально есть:

• KVM/полная виртуализация — у тебя своё, изолированное ядро Linux (или Windows). Можно грузить свои модули ядра, менять параметры sysctl, ставить любой дистрибутив при переустановке. Это то, что называют "как отдельный сервер, только виртуальный".
• OpenVZ/LXC-контейнеры — все контейнеры на хосте делят одно ядро хост-машины. Ты не можешь менять параметры ядра, грузить модули, иногда даже iptables работает с оговорками. Зато такие тарифы обычно дешевле.

Если статья про твой сервер начинается с "не могу изменить sysctl" или "модуль не грузится" — первым делом проверь, KVM у тебя или контейнер. Половина проблем с "недоступными правами" — это не заговор хостера, а особенность архитектуры тарифа. Разница между этими подходами подробнее разобрана в статье VPS или специализированный игровой хостинг — в чём разница.

Что действительно твоё: полный root внутри своей ОС

На нормальном KVM-тарифе для игрового сервера у арендатора есть root-доступ (или Administrator на Windows) внутри своей операционной системы. Это значит:

• Полный контроль над файловой системой — от /etc до содержимого /home, включая права доступа, владельцев файлов, ACL.
• Управление процессами и сервисами — можно ставить свои systemd-юниты, настраивать автозапуск игрового процесса при перезагрузке хоста (подробнее — в статье автозапуск игрового сервера при перезагрузке хоста).
• Установка любого софта из репозиториев или сборка из исходников — SteamCMD, Java нужной версии, Docker, мониторинг вроде Zabbix или связки Grafana + Prometheus.
• Локальный файрвол внутри своей ОС (iptables/nftables/Windows Firewall) — на уровне твоей виртуалки ты сам решаешь, какие порты открыты изнутри.
• SSH-доступ, ключи, пользователи, sudo-права для со-администраторов — здесь ты полноценный владелец. Если пускаешь на сервер ещё пары человек в команду, лучше сразу настроить доступ по ключам, а не общим паролем — это разобрано в статье про SSH-ключи вместо пароля для нескольких администраторов сервера.
• Собственные образы бэкапов на уровне файлов и БД — что и как бэкапить, ты выбираешь сам.

Важный нюанс: root внутри гостевой ОС — это root только внутри неё. Ты не можешь "выйти" за пределы своей виртуальной машины и повлиять на соседей по хосту, даже если очень хочется выжать больше CPU.

Что никогда не будет твоим: слой гипервизора и физика хоста

Вот зона, куда арендатор в принципе не заходит, сколько бы root ни было внутри гостевой ОС:

• Ядро хост-системы и сам гипервизор — недоступны по определению архитектуры. Даже у провайдера обычно нет "ручного" доступа к гипервизору без специальных процедур — это управляется оркестрацией (Proxmox, OpenStack и аналоги).
• Физическое железо — конкретный процессор, слот RAM, дисковый массив под виртуалкой. Ты не выбираешь модель CPU, не меняешь RAID-контроллер, не переставляешь диски.
• Сетевая инфраструктура выше твоего интерфейса — магистральные маршрутизаторы, аплинки, DDoS-фильтрация на границе сети. Ты настраиваешь файрвол внутри своей ОС, но не трогаешь коммутаторы дата-центра.
• Гипервизорные лимиты и шейпинг — CPU quota, I/O throttling, сетевые лимиты, которые накладываются "снаружи" виртуалки. Изнутри гостевой ОС ты их даже не всегда увидишь напрямую — просто упрёшься в потолок.
• Живая миграция, снапшоты на уровне хоста, резервирование ресурсов — это инструменты провайдера для обслуживания парка серверов, а не твои функции.
• BIOS/UEFI хоста, микрокод, прошивки контроллеров — вообще не в зоне видимости арендатора.

Если тикет в поддержку получает ответ "недоступно на уровне гипервизора" — это не отговорка, а технический факт: провайдер физически не даёт этот рычаг ни одному арендатору, потому что от него зависит стабильность всех соседних виртуалок на том же хосте.

Сеть и порты: где граница твоей ответственности

Сетевая часть — источник половины путаницы про "права". Разложим по слоям:

На практике это значит: ты полностью управляешь тем, какие порты открыты у твоего игрового сервера — 25565 для Minecraft, 27015-27020 для CS2, 2456-2458 для Valheim, и так далее — через свой файрвол. Подробная настройка описана в статье настройка портов и файрвола для игрового сервера. Но если DDoS идёт не на конкретный порт, а забивает весь канал до хоста — здесь работает только защита на стороне хостера, и это то, что стоит уточнять при выборе тарифа, а не после инцидента.

Отдельно: если хочешь запретить доступ к панели администратора или RCON только со своего IP — это тоже полностью твоя зона, разбирается в статье про ограничение доступа по IP для игрового сервера.

Ресурсы: лимиты, throttling и "почему сервер тормозит, а я ничего не менял"

Тут arendator часто путает свои права с чужими обязательствами. Разберём типичные ситуации:

CPU steal time. Если на хосте виртуализация с переподпиской (oversell), твой тикрейт может проседать не из-за твоей конфигурации, а из-за соседей по хосту, которые в моменте жрут CPU сверх своей квоты. Изнутри гостевой ОС это видно по метрике %st (steal) в top/htop — если она стабильно выше нескольких процентов, это повод писать в поддержку, а не оптимизировать конфиг ещё раз. Ты не можешь исправить это сам — можешь только диагностировать и запросить перенос на менее нагруженный хост.

RAM. Обычно RAM у VPS выделена жёстко (не oversell), но стоит уточнять у конкретного провайдера. Если память "своя" — OOM killer внутри твоей ОС полностью в твоей власти: можно настраивать swappiness, лимиты через systemd (MemoryMax=), приоритеты для игрового процесса.

Дисковый I/O. Часто лимитируется на уровне гипервизора (IOPS-квота), и внутри гостевой ОС ты просто упираешься в потолок без возможности его поднять — разве что через апгрейд тарифа.

Сетевая полоса. Аналогично — есть заявленный канал, и превысить его штатными средствами внутри своей ОС нельзя, только апгрейдом или запросом к хостеру.

Если после всех проверок конфигурации сервер всё равно "проседает" необъяснимо — прежде чем что-то трогать в своей ОС, пройди чек-лист диагностики из статьи сервер завис — самостоятельная диагностика перед обращением в поддержку: это поможет отличить "проблема в моей конфигурации" от "проблема на стороне хоста", и разговор с поддержкой будет предметным, а не "у меня лагает, помогите".

Когда своих прав не хватает: апгрейд, а не борьба с ограничениями

Если ты упёрся в реальный потолок — не root-доступа, а именно архитектурный (нужен другой процессор, гарантированный CPU без steal time, кастомное ядро с модулями, которых нет в контейнерной виртуализации) — вариантов немного, и все они не про "выбить больше прав у поддержки":

1. Перейти с контейнерной виртуализации (OpenVZ/LXC) на KVM — если сейчас у тебя контейнер и не хватает контроля над ядром, это первый и самый дешёвый шаг.
2. Апгрейд тарифа на выделенные ресурсы (без oversell CPU) — снимает проблему steal time и нестабильного тикрейта под пиковой нагрузкой.
3. Переход на выделенный физический сервер — когда нужен реальный контроль над железом, кастомные RAID-конфигурации или прошивки, которые ни один VPS не даст в принципе. Здесь стоит сначала прикинуть, оправдан ли переход именно для твоего проекта — сравнение подходов есть в статье выделенный сервер или VPS для крупного модпака.
4. Написать в поддержку с конкретным техническим запросом, а не общей жалобой — "нужен модуль ядра X" или "нужна гарантия CPU без steal" звучит для инженера поддержки понятнее, чем "у меня лагает".

Если решаешь мигрировать на другой тариф или к другому хостеру, важно сделать это без потери мира и прогресса игроков — процесс описан в статье миграция сервера к другому хостеру без потери мира.

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