Tactical RMM на VPS: своя система удалённого администрирования

Что мы настраиваем и зачем

Tactical RMM — система удалённого мониторинга и управления конечными устройствами. Её обычно используют системные администраторы, небольшие IT-команды, MSP-провайдеры, разработчики и владельцы нескольких серверов или рабочих станций. В отличие от обычного SSH-доступа, RMM-платформа показывает состояние всех машин в одной панели, умеет запускать автоматизацию по расписанию и фиксирует действия операторов.

После настройки на VPS вы получите веб-панель, в которой можно группировать устройства по клиентам, сайтам и ролям. Например, отдельно вести офисные ПК, серверы приложений, ноутбуки разработчиков и тестовые виртуальные машины. На устройства устанавливается агент Tactical RMM; он передаёт телеметрию, принимает команды и выполняет назначенные проверки.

Что умеет Tactical RMM

• Инвентаризация оборудования, ОС, дисков, сервисов и установленного ПО.
• Мониторинг доступности, загрузки CPU, RAM, дискового пространства и пользовательских проверок.
• Удалённое выполнение PowerShell, Bash, Python и других скриптов.
• Планировщик задач: обновления, очистка временных файлов, перезапуск служб, инвентаризация.
• Удалённый доступ через MeshCentral и поддержку терминальных сессий.
• Алерты по e-mail, вебхукам и интеграциям с внешними системами.
• Управление патчами Windows и сценариями обслуживания.
• Аудит действий операторов и история результатов скриптов.

Почему не облачный RMM

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

Self-hosted Tactical RMM даёт контроль над данными, DNS, сертификатами, сроком хранения логов и доступом операторов. Это полезно для внутренней инфраструктуры, небольших MSP-команд, лабораторий, homelab-сред и организаций с требованиями к расположению данных. Минус — сервер, обновления, безопасность и резервное копирование становятся вашей ответственностью.

Важно: RMM-сервер имеет привилегированный доступ к управляемым устройствам. Компрометация панели означает риск компрометации всей инфраструктуры. Используйте уникальные пароли, MFA, ограничение доступа, регулярные обновления и резервные копии.

Какой VPS-конфиг нужен под эту задачу

Нагрузка Tactical RMM зависит не только от числа агентов, но и от частоты проверок, хранения логов, числа одновременных удалённых сессий, объёма автоматизации и использования MeshCentral. Для старта не стоит выбирать VPS с 1–2 ГБ RAM: PostgreSQL, контейнеры приложения, брокер сообщений и сервис удалённого доступа будут конкурировать за память.

Практичный стартовый вариант — 4 vCPU, 8 ГБ RAM, 120 ГБ NVMe и канал от 100 Мбит/с. Такой запас позволяет обслуживать десятки агентов, хранить историю проверок и не сталкиваться с постоянным OOM при обновлениях контейнеров. В качестве одного из вариантов можно взять VPS с указанными характеристиками, но важнее наличие SSD/NVMe, статического IPv4, стабильной сети и возможности делать снапшоты.

Диск и сеть

Для базы данных важнее задержки и IOPS, чем большой объём медленного HDD. Минимум 30–40% диска держите свободными: PostgreSQL, журналы контейнеров, временные файлы и бэкапы могут быстро заполнить раздел. Если в панели много устройств с частыми проверками, заранее настройте ротацию Docker-логов.

Исходящий трафик обычно умеренный, но возрастает во время удалённых сессий, передачи файлов и массовой установки агентов. Для 50–100 устройств достаточно 100 Мбит/с, однако для частого удалённого доступа предпочтительнее 1 Гбит/с. Проверьте, что провайдер не блокирует входящие 80/TCP и 443/TCP: они требуются для выпуска и продления TLS-сертификатов.

Когда нужен dedicated, а не VPS

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

Для 20–150 устройств качественный VPS обычно проще и экономичнее. Масштабирование лучше начинать не с перехода на выделенный сервер, а с оптимизации интервалов проверок, очистки истории, вынесения бэкапов и увеличения RAM. Не размещайте Tactical RMM на VPS, который одновременно выполняет роль публичного сайта, почтового сервера и базы данных критичного приложения.

Выбор локации

Локация влияет на задержку удалённых сессий, требования к юрисдикции данных и скорость подключения агентов. Если большинство сотрудников находится в Европе, выбирайте европейский дата-центр; для локальной команды в одном регионе желательно держать сервер рядом с ней. При этом агенты подключаются по HTTPS, поэтому физическое нахождение устройства в другой стране не является проблемой, если соединение стабильно.

Подготовка сервера

Ниже используется Ubuntu Server 24.04 LTS. На 2026 год это актуальная LTS-платформа с длительным сроком поддержки. Разворачивайте сервер из чистого образа, назначьте ему полное доменное имя и до установки создайте DNS-записи типа A.

Для примера будут использоваться три поддомена:

• rmm.example.com — веб-панель Tactical RMM.
• api.rmm.example.com — API и регистрация агентов.
• mesh.rmm.example.com — MeshCentral для удалённого доступа.

Замените example.com на собственный домен во всех командах и конфигурационных файлах. Все три записи должны указывать на публичный IPv4-адрес VPS до получения сертификатов.

Создание администратора и настройка SSH

Подключитесь к серверу как root только один раз, создайте отдельного пользователя и добавьте ваш публичный SSH-ключ. После проверки входа под новым пользователем отключите парольную аутентификацию.

# Создаёт отдельного пользователя для администрирования.
adduser deploy

# Добавляет пользователя в группу sudo.
usermod -aG sudo deploy

# Создаёт каталог для SSH-ключей.
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

# Добавляет ваш публичный ключ; замените содержимое ключом из ~/.ssh/id_ed25519.pub.
nano /home/deploy/.ssh/authorized_keys

# Устанавливает безопасные права на файл ключей.
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Откройте вторую SSH-сессию и убедитесь, что вход под пользователем deploy работает. Только после этого меняйте настройки SSH.

# Открывает настройки SSH-демона.
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

# Проверяет синтаксис конфигурации SSH.
sudo sshd -t

# Перезапускает SSH после успешной проверки.
sudo systemctl restart ssh

В файле /etc/ssh/sshd_config.d/99-hardening.conf разместите следующее:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
AllowUsers deploy

Обновление и базовые утилиты

Сначала установите обновления. Tactical RMM — сервис, который будет доступен из интернета, поэтому не откладывайте исправления ядра, OpenSSL, Docker и веб-сервера.

# Обновляет индекс пакетов и устанавливает актуальные исправления.
sudo apt update && sudo apt full-upgrade -y

# Устанавливает базовые инструменты диагностики и администрирования.
sudo apt install -y ca-certificates curl gnupg git jq unzip \
  htop ncdu dnsutils chrony ufw fail2ban

# Включает синхронизацию времени, важную для TLS и журналов.
sudo systemctl enable --now chrony

# Проверяет текущую синхронизацию времени.
timedatectl status

Firewall и Fail2ban

Открывайте только SSH и веб-порты. Не открывайте PostgreSQL, NATS, Redis, внутренние API и порты контейнеров во внешний интернет. Docker-контейнеры должны быть доступны через reverse proxy или внутреннюю сеть Compose.

# Разрешает SSH до включения firewall, чтобы не потерять доступ.
sudo ufw allow OpenSSH

# Разрешает HTTP для ACME-проверки и HTTPS для панели и агентов.
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Включает firewall и показывает активные правила.
sudo ufw enable
sudo ufw status verbose

# Включает Fail2ban для защиты SSH от перебора паролей.
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Если вы администрируете сервер только с постоянного IP-адреса, дополнительно ограничьте SSH этим адресом. Не делайте этого при динамическом домашнем IP без аварийного доступа через консоль провайдера.

# Пример: разрешает SSH только с доверенного IP-адреса.
sudo ufw delete allow OpenSSH
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Установка ПО — пошагово

Tactical RMM состоит из нескольких сервисов: веб-приложения, API, PostgreSQL, брокера сообщений, MeshCentral и компонентов фоновых задач. Наиболее безопасный путь — использовать официальный установщик проекта, который создаёт согласованную конфигурацию и контейнеры. Перед запуском прочитайте содержимое загруженного скрипта: он выполняется с правами root.

В этой схеме используется Docker Engine 27+ или 28+ и современный Docker Compose plugin. Версии образов Tactical RMM меняются быстрее, чем версии Ubuntu, поэтому не фиксируйте непроверенный тег вручную: официальный установщик обычно выбирает совместимый стабильный выпуск.

Установка Docker Engine

# Удаляет старые конфликтующие пакеты Docker, если они присутствуют.
sudo apt remove -y docker.io docker-compose docker-compose-v2 podman-docker || true

# Добавляет официальный ключ репозитория Docker.
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Добавляет официальный репозиторий Docker для текущего релиза Ubuntu.
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Устанавливает Docker Engine, CLI и плагин Docker Compose.
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

# Включает Docker и проверяет установленную версию.
sudo systemctl enable --now docker
docker version
docker compose version

Разрешите пользователю deploy работать с Docker без постоянного sudo. После выполнения команды выйдите из SSH-сессии и подключитесь заново.

# Добавляет администратора в группу docker.
sudo usermod -aG docker deploy

# Создаёт каталог для установки и обслуживания Tactical RMM.
sudo install -d -m 0750 -o deploy -g deploy /opt/tacticalrmm

Проверка DNS до установки

Неверные DNS-записи — одна из самых частых причин неудачного выпуска TLS-сертификата. Проверьте каждый поддомен с самого VPS и с внешнего компьютера. Команда должна вернуть публичный IP сервера.

# Проверяет, что все доменные имена указывают на IP VPS.
dig +short rmm.example.com A
dig +short api.rmm.example.com A
dig +short mesh.rmm.example.com A

# Показывает публичный IP-адрес, с которого VPS выходит в интернет.
curl -4 ifconfig.me

Загрузка официального установщика Tactical RMM

Официальный проект поддерживает установочный скрипт в репозитории Tactical RMM. Перед запуском сохраните его локально, проверьте первые строки и при необходимости изучите полный код. Не используйте однострочные конструкции вида curl | bash для серверов, которыми вы управляете в production.

# Переходит в рабочий каталог установки.
cd /opt/tacticalrmm

# Загружает официальный установочный скрипт в локальный файл.
curl -fL \
  https://raw.githubusercontent.com/amidaware/tacticalrmm/master/install.sh \
  -o install.sh

# Разрешает запуск и показывает начало файла для ручной проверки.
chmod 700 install.sh
sed -n '1,120p' install.sh

# Показывает параметры, если скрипт поддерживает встроенную справку.
sudo ./install.sh --help || true

Названия параметров установщика могут меняться между релизами. Если скрипт предлагает интерактивный режим, выбирайте установку с Docker и указывайте три FQDN: для панели, API и MeshCentral. В процессе понадобятся e-mail для Let’s Encrypt и сильные пароли для внутренних сервисов.

# Запускает официальный интерактивный установщик с правами root.
sudo ./install.sh

Во время установки укажите:

• домен панели: rmm.example.com;
• домен API: api.rmm.example.com;
• домен MeshCentral: mesh.rmm.example.com;
• e-mail для уведомлений Let’s Encrypt;
• случайные уникальные секреты для базы данных, JWT и внутренних компонентов;
• публичный IP VPS, если установщик запрашивает его отдельно.

Проверка контейнеров

После завершения не считайте установку готовой, пока не проверите состояние сервисов. Контейнеры могут запускаться несколько минут, особенно при первом создании базы данных и выпуске сертификата.

# Показывает состояние сервисов в каталоге установки.
cd /opt/tacticalrmm
docker compose ps

# Показывает последние 200 строк логов всех контейнеров.
docker compose logs --tail=200

# Проверяет, что сервер слушает только ожидаемые внешние HTTP/HTTPS-порты.
sudo ss -lntp | grep -E ':(80|443)\s'

# Проверяет свободное место и использование памяти.
df -h
free -h

Откройте https://rmm.example.com в браузере. При первом входе создайте администратора только с уникальным длинным паролем. Затем включите MFA для всех операторов, создайте отдельные учётные записи сотрудников и не используйте общую учётную запись администратора.

Конфигурация

После базовой установки настройте домены, секреты, TLS, параметры журналирования и доступ операторов. Конкретные имена файлов зависят от версии официального установщика, но принцип один: секреты не должны попадать в Git-репозиторий, shell history, скриншоты и публичные paste-сервисы.

Файл окружения и секреты

Если ваш deployment использует Docker Compose, храните секреты в отдельном файле .env с правами 600. Не передавайте пароли через аргументы командной строки: они могут попасть в историю shell и список процессов.

# Создаёт каталог конфигурации, доступный только root.
sudo install -d -m 0700 /etc/tacticalrmm

# Генерирует криптографически стойкие секреты.
sudo bash -c 'umask 077; cat > /etc/tacticalrmm/.env <<EOF
POSTGRES_PASSWORD='$(openssl rand -base64 36)'
DJANGO_SECRET_KEY='$(openssl rand -base64 48)'
JWT_SECRET='$(openssl rand -base64 48)'
EOF'

# Ограничивает доступ к файлу с секретами.
sudo chmod 600 /etc/tacticalrmm/.env
sudo chown root:root /etc/tacticalrmm/.env

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

TLS через Caddy

Во многих вариантах установки Tactical RMM Caddy уже используется как reverse proxy. Если установщик создал Caddyfile, проверьте, что он проксирует только нужные сервисы, включает HTTPS и не публикует внутренние панели PostgreSQL или NATS.

Ниже приведён пример общей структуры Caddyfile. Порты контейнеров и пути API сверяйте с файлами, созданными вашим выпуском Tactical RMM. Не копируйте пример вслепую поверх рабочего Caddyfile: сначала сохраните резервную копию.

Caddyfile {
    email [email protected]
    servers {
        protocols h1 h2
    }
}

rmm.example.com {
    encode zstd gzip
    reverse_proxy tactical-frontend:8000
}

api.rmm.example.com {
    encode zstd gzip
    reverse_proxy tactical-api:8001
}

mesh.rmm.example.com {
    encode zstd gzip
    reverse_proxy meshcentral:4430
}

Перед применением любой конфигурации Caddy проверьте синтаксис. При работе Caddy внутри Docker используйте имя контейнера или команды из Compose; при установке как systemd-сервиса — системную команду.

# Сохраняет копию текущего Caddyfile перед редактированием.
sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak.$(date +%F) 2>/dev/null || true

# Проверяет конфигурацию локально установленного Caddy.
sudo caddy validate --config /etc/caddy/Caddyfile 2>/dev/null || true

# Перезагружает Caddy без разрыва активных соединений.
sudo systemctl reload caddy 2>/dev/null || true

Проверка HTTPS и API

Проверяйте не только открытие страницы в браузере, но и корректность TLS-цепочки, DNS, HTTP-ответа и доступности API. Ответ 200, 301, 302 или 401 на закрытом endpoint обычно означает, что reverse proxy работает; ошибка 502 говорит о недоступном backend-контейнере.

# Проверяет заголовки главной страницы и TLS-соединение.
curl -I --fail --max-time 15 https://rmm.example.com

# Проверяет, что API отвечает через HTTPS.
curl -I --max-time 15 https://api.rmm.example.com

# Проверяет сертификат, имя хоста и дату окончания действия.
echo | openssl s_client -connect rmm.example.com:443 \
  -servername rmm.example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

# Проверяет доступность MeshCentral по HTTPS.
curl -I --max-time 15 https://mesh.rmm.example.com

Первичная настройка в веб-панели

1. Создайте отдельную организацию или клиента для собственной инфраструктуры.
2. Создайте сайты: например, Office, Production, Home Lab.
3. Создайте технические группы устройств: Windows Servers, Linux Servers, Workstations.
4. Включите MFA для администратора до развёртывания агентов.
5. Настройте SMTP или webhook для критических уведомлений.
6. Создайте проверку свободного места: предупреждение при 15%, критический уровень при 5%.
7. Добавьте тестовую машину и проверьте выполнение безопасной команды.

Для теста на Linux назначьте скрипт, который не меняет систему:

# Показывает имя хоста, uptime, свободное место и версию ядра.
hostnamectl
uptime
df -h /
uname -r

Для Windows используйте PowerShell-сценарий:

# Показывает имя компьютера, версию ОС и свободное место на системном диске.
Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion
Get-PSDrive -Name C | Select-Object Name, Used, Free

Безопасность агентов: устанавливайте агент только через защищённую панель, не размещайте installer в открытом файловом каталоге и не отключайте проверку сертификатов. Для серверов сначала тестируйте скрипты на одной машине в отдельной группе.

Бэкапы и обслуживание

Снапшот VPS полезен, но не заменяет резервную копию. Он может находиться в том же дата-центре, быть недоступным при ошибке аккаунта и не гарантировать консистентность базы во время записи. Для Tactical RMM нужны как минимум ежедневные резервные копии PostgreSQL, конфигурации reverse proxy, файлов Compose, переменных окружения и постоянных Docker volumes.

Что включать в резервную копию

• Дамп PostgreSQL: пользователи, организации, агенты, политики, история и настройки.
• Каталог установки /opt/tacticalrmm, кроме ненужных временных файлов и больших логов.
• Конфигурации из /etc/tacticalrmm, /etc/caddy и связанные systemd unit-файлы.
• Список Docker volumes и данные MeshCentral, если они не входят в дамп БД.
• Документ с доменами, DNS-записями, списком операторов и процедурой восстановления.

Резервное копирование через restic

Restic поддерживает шифрование на стороне клиента и S3-совместимые хранилища. Пароль репозитория и ключи доступа не храните в самом бэкапе. Держите их в password manager или секретном хранилище, доступном при аварийном восстановлении.

# Устанавливает restic и утилиты PostgreSQL-клиента.
sudo apt install -y restic postgresql-client

# Создаёт каталоги для временных дампов и конфигурации бэкапов.
sudo install -d -m 0700 /var/backups/tacticalrmm /etc/restic

# Создаёт файл с паролем шифрования репозитория.
sudo bash -c 'umask 077; openssl rand -base64 48 > /etc/restic/tacticalrmm-password'

# Создаёт файл переменных для S3-совместимого хранилища.
sudo nano /etc/restic/tacticalrmm.env

Пример файла /etc/restic/tacticalrmm.env:

export RESTIC_REPOSITORY="s3:https://s3.example.net/tacticalrmm-backups"
export RESTIC_PASSWORD_FILE="/etc/restic/tacticalrmm-password"
export AWS_ACCESS_KEY_ID="CHANGE_ME"
export AWS_SECRET_ACCESS_KEY="CHANGE_ME"
export AWS_DEFAULT_REGION="us-east-1"

Создайте скрипт. Имя контейнера PostgreSQL уточните через docker compose ps; в примере оно ищется по имени сервиса. Если ваша установка использует другую схему, замените команду дампа на соответствующую.

# Создаёт ежедневный скрипт консистентного бэкапа.
sudo nano /usr/local/sbin/backup-tacticalrmm.sh

#!/usr/bin/env bash
set -euo pipefail

source /etc/restic/tacticalrmm.env

STAMP="$(date +%F_%H-%M-%S)"
BACKUP_DIR="/var/backups/tacticalrmm/${STAMP}"
mkdir -p "${BACKUP_DIR}"

cd /opt/tacticalrmm

docker compose exec -T postgres pg_dump -U postgres -Fc \
  tacticalrmm > "${BACKUP_DIR}/tacticalrmm.dump"

tar -czf "${BACKUP_DIR}/config.tar.gz" \
  /opt/tacticalrmm \
  /etc/tacticalrmm \
  /etc/caddy 2>/dev/null || true

restic backup "${BACKUP_DIR}" \
  --tag tacticalrmm \
  --tag daily

restic forget --prune \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12

rm -rf "${BACKUP_DIR}"

# Делает скрипт исполняемым и запускает тестовый бэкап вручную.
sudo chmod 700 /usr/local/sbin/backup-tacticalrmm.sh
sudo /usr/local/sbin/backup-tacticalrmm.sh

# Проверяет содержимое и целостность репозитория restic.
sudo bash -c 'source /etc/restic/tacticalrmm.env; restic snapshots'
sudo bash -c 'source /etc/restic/tacticalrmm.env; restic check'

Добавьте запуск по cron ночью. При большой базе лучше использовать systemd timer, так как он лучше ведёт журналы и может запускать пропущенные задания после перезагрузки, но cron достаточно для небольшой инсталляции.

# Открывает root-crontab для ежедневного запуска в 03:20.
sudo crontab -e

20 3   * /usr/local/sbin/backup-tacticalrmm.sh >> /var/log/tacticalrmm-backup.log 2>&1

Проверка восстановления

Бэкап считается рабочим только после теста восстановления. Раз в квартал разверните отдельный временный VPS, восстановите конфигурацию и базу, затем проверьте вход в панель и видимость тестовых устройств. Не проводите первый restore во время аварии.

Обновления

Для Tactical RMM используйте maintenance window, особенно если подключены серверы клиентов. Обновления могут менять схему базы данных, версии контейнеров и поведение агентов. Сначала создайте свежий бэкап, прочитайте release notes, протестируйте обновление на копии или тестовой инсталляции и только затем обновляйте production.

# Сохраняет состояние работающих образов перед обновлением.
cd /opt/tacticalrmm
docker compose images > /root/tacticalrmm-images-before-update.txt

# Создаёт бэкап перед изменением версий.
sudo /usr/local/sbin/backup-tacticalrmm.sh

# Загружает новые образы и применяет обновление по документации выпуска.
docker compose pull
docker compose up -d

# Проверяет состояние и последние журналы после обновления.
docker compose ps
docker compose logs --tail=150

Не выполняйте автоматическое обновление контейнеров через Watchtower или аналогичные инструменты без тестирования. Для RMM предпочтительнее контролируемое обновление в согласованное окно, потому что краткий сбой панели или несовместимость базы могут повлиять на множество агентов.

Troubleshooting и FAQ

Почему браузер показывает ошибку сертификата или Caddy не получает сертификат?

Сначала проверьте DNS: каждый поддомен должен возвращать публичный IPv4 VPS. Затем убедитесь, что порты 80/TCP и 443/TCP доступны извне, а firewall и внешний security group их не блокируют. Посмотрите логи Caddy или reverse proxy через docker compose logs. Частая причина — запись AAAA указывает на неработающий IPv6-сервер, либо другой веб-сервер уже занимает 80-й порт.

Почему панель открывается, но API отвечает ошибкой 502 Bad Gateway?

Код 502 означает, что reverse proxy работает, но не может подключиться к backend-сервису. Выполните docker compose ps и найдите контейнер в статусе exited, restarting или unhealthy. Затем откройте его логи: docker compose logs --tail=200 имя_сервиса. Проверьте RAM, свободный диск, значения переменных окружения и доступность PostgreSQL. Не удаляйте volumes до создания резервной копии.

Агент Tactical RMM не регистрируется или постоянно находится offline. Что делать?

Проверьте, что машина клиента может открыть https://api.rmm.example.com и https://mesh.rmm.example.com без TLS-ошибки. Корпоративный proxy, антивирус, EDR или firewall могут блокировать связь агента. Сверьте время на устройстве: сильное расхождение часов ломает проверку сертификатов. Также убедитесь, что installer агента был скачан из текущей панели и использует правильный URL API, а не старый домен.

После запуска контейнеров сервер начинает использовать swap или сервисы перезапускаются.

Обычно причина — нехватка RAM. Проверьте free -h, docker stats, dmesg -T | grep -i oom и размер Docker-логов. Для стабильной работы небольшой инсталляции рекомендуется 8 ГБ RAM; 4 ГБ подходит только для лабораторной нагрузки. Временно можно увеличить swap, но это не замена памяти: PostgreSQL и сервисы RMM будут работать медленнее. Уменьшите число тяжёлых проверок и обновите конфиг VPS.

Диск быстро заполняется. Какие данные можно очищать?

Сначала определите источник: используйте df -h, du -xh /var/lib/docker | sort -h | tail и docker system df. Часто растут Docker container logs, старые образы и архивы резервных копий, которые не были удалены после отправки во внешнее хранилище. Не удаляйте PostgreSQL volumes и данные MeshCentral командой docker system prune --volumes без точного понимания последствий. Настройте ротацию логов и хранение истории алертов.

Какой VPS-конфиг минимально подойдёт?

Для тестовой среды до 20 устройств подойдёт 2 vCPU, 4 ГБ RAM и 60 ГБ NVMe. Для практического использования с несколькими десятками устройств лучше начинать с 4 vCPU, 8 ГБ RAM и 100–120 ГБ NVMe. Важны стабильный статический IP, открытые 80 и 443 порты, нормальные дисковые IOPS и возможность хранить бэкапы вне основного сервера. Не рассчитывайте на 1 ГБ RAM.

Что выбрать — VPS или dedicated для этой задачи?

VPS подходит большинству небольших инсталляций до 100–150 устройств, если у него гарантированные ресурсы, NVMe-диск и стабильная сеть. Dedicated стоит выбирать при сотнях агентов, высокой активности удалённых сессий, больших сроках хранения логов, требованиях к изоляции или необходимости запускать рядом дополнительные сервисы. Начните с VPS и отслеживайте RAM, IOPS, нагрузку CPU и рост базы; миграция на выделенный сервер понадобится только при подтверждённой нагрузке.

Можно ли открыть панель только через VPN?

Да, и это хороший вариант для административного интерфейса. Можно ограничить доступ к rmm.example.com IP-адресами WireGuard-сети или правилами Caddy/firewall, оставив API и MeshCentral доступными агентам по HTTPS. Однако внимательно разделяйте пути и домены: если полностью закрыть API от интернета, устройства за NAT перестанут подключаться. Перед изменением правил протестируйте доступ с тестового агента вне вашей локальной сети.

Почему после обновления часть агентов перестала подключаться?

Проверьте release notes установленной версии, логи API, срок действия TLS-сертификата и изменения доменных имён. Если при обновлении менялся reverse proxy, возможно, не проксируются WebSocket-соединения, требуемые MeshCentral. Также убедитесь, что системное время VPS корректно и база успешно прошла миграции. При серьёзном сбое восстановите проверенный бэкап или откатите образы только по документированной процедуре, не смешивая версии базы и приложения.

Выводы и следующие шаги

Теперь у вас есть собственная инсталляция Tactical RMM на VPS: защищённый сервер, HTTPS-домены, контейнерная платформа, панель управления агентами и схема резервного копирования. Такая система позволяет централизованно обслуживать рабочие станции и серверы без зависимости от облачного RMM-сервиса.

1. Добавьте одну тестовую Windows-машину и один Linux-сервер, затем проверьте алерты, удалённые команды и доступ через MeshCentral.
2. Создайте библиотеку безопасных скриптов: проверка места, очистка временных файлов, обновление пакетов, перезапуск сервисов и инвентаризация.
3. Настройте MFA, роли операторов, внешние уведомления и регулярный тест восстановления резервной копии.

По мере роста числа устройств пересматривайте интервалы проверок, объём диска, срок хранения истории и доступную RAM. Сначала автоматизируйте повторяемые действия, затем при необходимости выносите бэкапы, мониторинг и отдельные компоненты на независимую инфраструктуру.