MeshCentral на VPS: удалённый доступ к сотне машин бесплатно

1. TL;DR

MeshCentral подходит для централизованного удалённого доступа к компьютерам под Windows, Linux и macOS. В отличие от обычного RDP или VNC, агент сам устанавливает исходящее соединение с сервером, поэтому не требуется открывать RDP-порты на каждой рабочей станции. Сервер MeshCentral размещается на вашем VPS, а администратор работает через защищённый веб-интерфейс.

В этой инструкции используется Ubuntu Server 24.04 LTS, Docker Engine 27 или новее, Docker Compose Plugin 2.x, MeshCentral из официального контейнерного образа и Caddy 2.10. Конфигурация рассчитана примерно на 100 постоянно подключённых машин при умеренной нагрузке: несколько параллельных сессий, периодические передачи файлов и удалённый терминал.

2. Содержание

Разделы выше образуют навигацию по инструкции. Если сервер уже подготовлен, можно перейти к установке Docker и MeshCentral, но перед этим важно проверить DNS, сетевые порты и требования к VPS.

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

Как работает MeshCentral

MeshCentral состоит из серверной части и MeshAgent. Сервер принимает подключения агентов, хранит список устройств и пользователей, а также предоставляет веб-интерфейс. Агент запускается на управляемой машине и поддерживает связь с сервером по HTTPS или WebSocket.

Когда оператор открывает удалённый рабочий стол, команда или передача файла, MeshCentral передаёт данные через сервер. Это удобно для компьютеров за NAT, домашними маршрутизаторами и корпоративными межсетевыми экранами: обычно достаточно разрешить исходящий HTTPS-трафик на клиенте.

Что будет получено в итоге

После выполнения инструкции будет работать веб-сайт вида https://mesh.example.com. В нём можно будет создать пользователя-администратора, организовать группы устройств и получить установщики агентов. Подключённые машины появятся в интерфейсе после запуска MeshAgent.

Доступ к серверу будет защищён TLS-сертификатом Let’s Encrypt. Сам VPS не должен содержать открытые порты RDP, VNC или SSH для общего интернета. SSH ограничивается вашим IP-адресом либо защищается ключами и дополнительными правилами firewall.

Self-hosted и cloud-managed варианты

Cloud-managed-сервисы берут на себя обновления, резервирование и эксплуатацию серверной части. Это удобно, если важны готовая поддержка, SLA и отсутствие собственного DevOps. Недостатки — абонентская плата, ограничения тарифов, зависимость от политики провайдера и передача метаданных об устройствах внешней компании.

Self-hosted MeshCentral на VPS требует самостоятельно обслуживать Linux, Docker, DNS, TLS и бэкапы. Зато данные, учётные записи и настройки находятся под вашим контролем. Для небольшой IT-службы, лаборатории, домашней инфраструктуры или MSP-проекта это часто оказывается практичнее платного облака.

Важно: слово «бесплатно» относится к программному обеспечению MeshCentral и отсутствию платы за устройство. Сам VPS, домен, резервное хранилище и время администратора могут быть платными.

Ограничения и модель безопасности

MeshCentral не заменяет полноценную систему управления конфигурациями, MDM или SIEM. Он даёт удалённый доступ и базовую инвентаризацию, но не должен быть единственным механизмом контроля обновлений и аудита в критической инфраструктуре.

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

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

Минимальная конфигурация

Для 20–30 подключённых компьютеров обычно достаточно 1–2 vCPU и 2 ГБ RAM. Для сотни агентов разумно начинать с 2 vCPU и 4 ГБ RAM. Сам агент потребляет ресурсы на клиентской машине, но серверу нужны память и CPU для WebSocket-соединений, TLS, хранения состояния и одновременных сессий.

Для целевой конфигурации можно взять подходящий VPS с 4 vCPU, 8 ГБ RAM, NVMe-диском от 80 ГБ, публичным IPv4-адресом и каналом от 100 Мбит/с. Такой запас полезен, если одновременно работают несколько операторов, выполняются резервные копии или на том же сервере размещаются вспомогательные контейнеры.

Диск и резервирование

Основная база MeshCentral небольшая, но передача файлов, журналы и резервные копии быстро увеличивают объём. Для установки на сотню машин достаточно 40 ГБ, если не хранить большие файлы на сервере. NVMe предпочтительнее обычного HDD, особенно при архивировании и восстановлении.

Не считайте локальный диск VPS резервной копией. Минимум одна копия должна находиться во внешнем S3-совместимом хранилище, на другом VPS или на отдельном физическом сервере. Желательно использовать шифрование до отправки данных.

Когда нужен dedicated

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

Для ста офисных компьютеров с редкими подключениями dedicated обычно избыточен. Сначала измерьте CPU, RAM, сетевой трафик и задержки на VPS, а затем увеличивайте ресурсы вертикально либо выносите MeshCentral на отдельный сервер.

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

Расположение VPS влияет прежде всего на задержку до операторов и клиентов. Для удалённого рабочего стола желательно выбирать регион, до которого от большинства пользователей менее 80–100 мс. Агентам в разных странах сервер может быть одинаково доступен, но качество интерактивной сессии будет отличаться.

Проверьте доступность исходящего и входящего TCP 443, наличие публичного IPv4 или корректного IPv6, правила abuse-политики и возможность создавать PTR-запись. Для обычного MeshCentral PTR не обязателен, однако аккуратная DNS-конфигурация облегчает диагностику.

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

Исходные условия

Ниже предполагается чистый Ubuntu Server 24.04 LTS с root-доступом и доменом mesh.example.com. Замените этот домен на свой. DNS-запись типа A должна указывать на IPv4-адрес VPS, а запись AAAA — только если IPv6 действительно настроен и доступен.

# Проверяем адрес сервера и имя хоста
hostnamectl

# Создаём A-запись заранее и проверяем её с локального компьютера
dig +short mesh.example.com

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

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

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

После обновления ядра проверьте, требуется ли перезагрузка. Если это новый сервер, перезагрузите его до продолжения, чтобы не оставить старую версию ядра.

# Показываем, требуется ли перезагрузка после обновлений
if [ -f /var/run/reboot-required ]; then echo "Reboot required"; fi

# Перезагружаем сервер при необходимости
sudo reboot

Пользователь и SSH-ключи

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

# Выполняется на вашем локальном компьютере: создаём ключ администратора
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/meshcentral_admin

# На VPS создаём отдельного администратора
sudo adduser deploy
sudo usermod -aG sudo deploy

# Создаём каталог SSH и задаём корректные права
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

Скопируйте содержимое файла ~/.ssh/meshcentral_admin.pub в /home/deploy/.ssh/authorized_keys. Если первоначальный доступ был по паролю, проверьте новый вход в отдельном окне, прежде чем отключать root и пароль.

# Пример передачи публичного ключа с локального компьютера
ssh-copy-id -i ~/.ssh/meshcentral_admin.pub deploy@SERVER_IP

# Проверяем вход новым пользователем
ssh -i ~/.ssh/meshcentral_admin deploy@SERVER_IP

SSH и firewall

Сначала разрешите SSH, HTTPS и HTTP для получения сертификата. Если вы знаете свой постоянный IP-адрес, лучше ограничить SSH правилом allow from. В примере ниже порт 22 открыт временно для всех; после проверки его следует ограничить.

# Разрешаем SSH, HTTP и HTTPS до включения firewall
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Включаем firewall с политикой запрета входящих соединений
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

# Проверяем активные правила
sudo ufw status verbose

После проверки SSH замените общее правило конкретным адресом, например 203.0.113.10.

# Удаляем общее правило SSH
sudo ufw delete allow 22/tcp

# Разрешаем SSH только с доверенного внешнего IP
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Fail2ban

Fail2ban отслеживает неудачные попытки входа и временно блокирует адреса нарушителей. Он не заменяет SSH-ключи и firewall, но уменьшает шум от автоматического перебора.

# Создаём локальную конфигурацию защиты SSH
sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
banaction = ufw
maxretry = 5
findtime = 10m
bantime = 1h
EOF

# Перезапускаем fail2ban и проверяем состояние jail
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

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

Установка Docker Engine

Вместо пакетов из случайных репозиториев используйте официальный apt-репозиторий Docker. На 2026 год для Ubuntu Server 24.04 подходит Docker Engine 27+ и Compose Plugin 2.x. Конкретная минорная версия будет зависеть от текущего репозитория.

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

# Создаём каталог для ключей репозиториев
sudo install -m 0755 -d /etc/apt/keyrings

# Загружаем официальный ключ Docker и ограничиваем его права
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, Buildx и Compose Plugin
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Проверяем версии и состояние службы
sudo docker version
sudo docker compose version
sudo systemctl enable --now docker

Добавлять пользователя в группу docker удобно, но эта группа фактически даёт root-права через Docker socket. Для небольшого отдельного VPS можно использовать sudo docker, не расширяя права пользователя.

Создание каталогов проекта

# Создаём каталоги MeshCentral и отдельный каталог для Caddy
sudo mkdir -p /opt/meshcentral/{meshcentral-data,meshcentral-files}
sudo mkdir -p /opt/caddy/{data,config}

# Передаём рабочие каталоги пользователю deploy
sudo chown -R deploy:deploy /opt/meshcentral /opt/caddy

# Переходим в каталог проекта
cd /opt/meshcentral

Файл переменных окружения

Секреты и доменное имя храним в файле .env, а не в YAML-файле, который проще случайно отправить в Git. Файл должен быть доступен только владельцу.

# Создаём переменные проекта
cat > /opt/meshcentral/.env <<'EOF'
MESH_DOMAIN=mesh.example.com
[email protected]
TZ=Europe/Moscow
EOF

# Ограничиваем доступ к переменным окружения
chmod 600 /opt/meshcentral/.env

Docker Compose

Официальный проект MeshCentral публикует контейнерный образ в реестре GitHub Container Registry. Тег latest удобен для первого запуска, но в рабочей среде лучше зафиксировать проверенный тег после тестирования обновления. Пример ниже использует образ ghcr.io/ylianst/meshcentral:latest; перед обновлением сверяйте поддерживаемые теги в официальном репозитории проекта.

# Создаём Compose-файл для MeshCentral и Caddy
cat > /opt/meshcentral/compose.yml <<'EOF'
services:
  meshcentral:
    image: ghcr.io/ylianst/meshcentral:latest
    container_name: meshcentral
    restart: unless-stopped
    environment:
      TZ: ${TZ}
    volumes:
      - ./meshcentral-data:/opt/meshcentral/meshcentral-data
      - ./meshcentral-files:/opt/meshcentral/meshcentral-files
    expose:
      - "4433"
    networks:
      - meshnet

  caddy:
    image: caddy:2.10-alpine
    container_name: meshcentral-caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - /opt/caddy/data:/data
      - /opt/caddy/config:/config
    depends_on:
      - meshcentral
    networks:
      - meshnet

networks:
  meshnet:
    driver: bridge
EOF

MeshCentral слушает внутри Docker-сети на порту 4433. Публиковать этот порт наружу не нужно: единственной внешней точкой входа будет Caddy на TCP 80 и 443.

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

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

Создайте файл config.json в каталоге данных. Значение WANonly включает режим сервера для удалённых устройств. Параметр webProxy позволяет MeshCentral корректно работать за обратным прокси, а AliasPort задаёт внешний HTTPS-порт, который видят агенты.

# Создаём конфигурацию MeshCentral
cat > /opt/meshcentral/meshcentral-data/config.json <<'EOF'
{
  "settings": {
    "cert": "mesh.example.com",
    "WANonly": true,
    "WebRTC": true,
    "WebRTCTrusted": true,
    "sessionTime": 30,
    "MaxInvalidLogin": 10,
    "AccountLoginToken": true,
    "WebPasswordReset": false,
    "minify": true,
    "agentPong": 300,
    "desktopMultiplex": true
  },
  "domains": {
    "": {
      "title": "MeshCentral",
      "title2": "Remote Management",
      "newAccounts": false,
      "userConsentFlags": 7,
      "passwordRequirements": {
        "min": 14,
        "upper": 1,
        "lower": 1,
        "numeric": 1,
        "nonalpha": 1
      },
      "logDeviceViews": true,
      "logDeviceNotes": true,
      "desktopPrivacyBarText": "Удалённая сессия активна",
      "terminal": true,
      "fileAccess": true,
      "agentConsole": true
    }
  }
}
EOF

# Защищаем конфигурацию от чтения другими пользователями
chmod 600 /opt/meshcentral/meshcentral-data/config.json

Значение newAccounts: false отключает открытую регистрацию. Первого администратора обычно создают через веб-интерфейс при первом запуске, если контейнер использует стандартный механизм MeshCentral. После создания администратора проверьте, что публичная регистрация действительно закрыта.

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

Обратный прокси Caddy

Caddy автоматически получает и продлевает сертификат Let’s Encrypt. Для успешной выдачи сертификата DNS уже должен указывать на VPS, а TCP 80 и 443 должны быть доступны из интернета.

# Создаём конфигурацию Caddy
cat > /opt/meshcentral/Caddyfile <<'EOF'
mesh.example.com {
    encode gzip zstd

    reverse_proxy meshcentral:4433 {
        transport http {
            tls_insecure_skip_verify
        }
    }

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    log {
        output file /data/access.log
        format json
    }
}
EOF

# Запускаем контейнеры в фоновом режиме
cd /opt/meshcentral
sudo docker compose --env-file .env -f compose.yml up -d

# Проверяем состояние контейнеров
sudo docker compose ps

В некоторых версиях MeshCentral внутренний HTTPS-сервер использует самоподписанный сертификат. Поэтому в блоке transport http задано tls_insecure_skip_verify. Это соединение происходит только внутри Docker-сети; внешний TLS завершается на Caddy. Не используйте этот параметр для проксирования произвольного внешнего сервиса.

Проверка DNS, TLS и HTTP

# Проверяем, что домен указывает на VPS
dig +short mesh.example.com

# Проверяем открытые локальные порты
sudo ss -tulpn | grep -E ':(80|443)\b'

# Смотрим последние логи MeshCentral
sudo docker logs --tail=100 meshcentral

# Смотрим логи Caddy
sudo docker logs --tail=100 meshcentral-caddy

# Проверяем HTTPS с сервера
curl -I https://mesh.example.com

# Проверяем доступность через внешний DNS и TLS
curl -fsS https://mesh.example.com/ | head

Ожидаемым результатом является ответ HTTP 200 или перенаправление на страницу входа. Ошибка 502 означает, что Caddy не может подключиться к MeshCentral. Ошибка сертификата обычно связана с DNS, закрытым портом 80 или неверным временем на сервере.

Первый вход и создание группы

Откройте https://mesh.example.com в браузере. Создайте длинную парольную фразу не менее 14 символов и включите двухфакторную аутентификацию TOTP в профиле пользователя, если эта возможность доступна в установленной версии.

Создайте отдельные группы: например, «Офис», «Домашние ПК», «Клиенты» и «Серверы». Не выдавайте оператору доступ ко всему серверу, если ему требуется только одна группа. Для каждого сотрудника используйте отдельную учётную запись, чтобы действия отражались в журналах.

Установка MeshAgent на клиентские машины

В интерфейсе MeshCentral откройте нужную группу устройств и выберите добавление компьютера. Скачайте установщик агента для соответствующей ОС и передайте его пользователю безопасным каналом либо разверните через существующую систему управления.

В Windows агент устанавливается от имени администратора как служба. В Linux потребуется root-доступ, а в macOS — разрешения Accessibility и Screen Recording. Без этих разрешений агент может быть подключён, но удалённый рабочий стол и управление вводом будут ограничены.

Для массовой установки не вставляйте токены приглашения в публичные скрипты. Используйте групповые политики, Intune, Ansible, Salt, существующий RMM или другой внутренний механизм распространения. После установки проверьте, что агент появился в правильной группе и получил ожидаемые права.

Проверка удалённой сессии

1. Убедитесь, что устройство отображается как подключённое.
2. Откройте информацию об устройстве и проверьте имя ОС, IP-адрес и время последнего контакта.
3. Запустите терминал и выполните безопасную команду, например whoami или hostname.
4. Проверьте передачу небольшого текстового файла.
5. Откройте рабочий стол и завершите сессию штатной кнопкой.
6. Проверьте журнал действий администратора.

Проверка перезапуска и автозапуска

# Перезапускаем стек без удаления данных
cd /opt/meshcentral
sudo docker compose restart

# Проверяем, что контейнеры запускаются после перезагрузки
sudo reboot

# После подключения проверяем статус
sudo docker compose ps
sudo systemctl is-enabled docker

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

Что необходимо сохранять

Критически важен каталог meshcentral-data. В нём находится конфигурация, база данных, ключи сервера, сертификаты и состояние устройств. Если потерять ключи или базу, агенты могут потребовать повторной регистрации, а пользователи и группы будут недоступны.

Каталог meshcentral-files содержит пользовательские файлы и данные, связанные с передачей файлов. Каталоги Caddy /opt/caddy/data и /opt/caddy/config хранят сертификаты и служебные данные прокси. Бэкап Compose-файла, Caddyfile и .env также обязателен, но секреты в нём должны быть зашифрованы.

Установка Restic

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

# Устанавливаем Restic из репозитория Ubuntu
sudo apt update
sudo apt install -y restic

# Создаём закрытый файл с параметрами удалённого хранилища
sudo install -m 600 -o root -g root /dev/null /root/.restic-env

sudo tee /root/.restic-env > /dev/null <<'EOF'
export AWS_ACCESS_KEY_ID='REPLACE_ACCESS_KEY'
export AWS_SECRET_ACCESS_KEY='REPLACE_SECRET_KEY'
export RESTIC_REPOSITORY='s3:https://s3.example.net/meshcentral'
export RESTIC_PASSWORD='REPLACE_LONG_RANDOM_PASSWORD'
EOF

Сгенерируйте отдельный пароль репозитория длиной не менее 32 случайных символов и сохраните его в менеджере паролей. Потеря пароля Restic означает потерю возможности расшифровать архив.

Скрипт автобэкапа

# Создаём скрипт резервного копирования
sudo tee /usr/local/sbin/meshcentral-backup > /dev/null <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail

source /root/.restic-env

export RESTIC_COMPRESSION=auto
export RESTIC_CACHE_DIR=/var/cache/restic

restic snapshots >/dev/null 2>&1 || \
  restic init

restic backup \
  /opt/meshcentral \
  /opt/caddy \
  --tag meshcentral \
  --exclude '/opt/meshcentral/meshcentral-files/tmp'

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

restic check --read-data-subset=5%
EOF

# Делаем скрипт исполняемым
sudo chmod 700 /usr/local/sbin/meshcentral-backup

# Запускаем первый бэкап вручную
sudo /usr/local/sbin/meshcentral-backup

Для ежедневного запуска создайте systemd timer либо cron. Вариант с cron проще, но systemd удобнее для журналирования.

# Добавляем ежедневный запуск в 03:30
sudo tee /etc/cron.d/meshcentral-backup > /dev/null <<'EOF'
30 3   * root /usr/local/sbin/meshcentral-backup >> /var/log/meshcentral-backup.log 2>&1
EOF

# Проверяем размер и наличие последних архивов
sudo bash -c 'source /root/.restic-env && restic snapshots --tag meshcentral'

Тест восстановления

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

# Восстанавливаем последний снимок во временный каталог
sudo mkdir -p /var/tmp/meshcentral-restore
sudo bash -c 'source /root/.restic-env && restic restore latest \
  --tag meshcentral --target /var/tmp/meshcentral-restore'

# Проверяем наличие ключевых файлов
sudo find /var/tmp/meshcentral-restore/opt/meshcentral \
  -maxdepth 3 -type f | head -30

Обновление MeshCentral и Docker

Не обновляйте production-установку автоматически каждую ночь. Сначала изучите изменения версии, сделайте полный бэкап, затем обновите образ в запланированное окно обслуживания. Для сотни агентов лучше сначала проверить обновление на отдельной тестовой группе из нескольких машин.

# Сохраняем текущие версии и делаем резервную копию
cd /opt/meshcentral
sudo docker compose images
sudo /usr/local/sbin/meshcentral-backup

# Получаем новый образ
sudo docker compose pull meshcentral caddy

# Пересоздаём контейнеры без удаления volume-каталогов
sudo docker compose up -d

# Проверяем статус и логи после обновления
sudo docker compose ps
sudo docker logs --tail=200 meshcentral

Если новая версия несовместима, верните предыдущий тег образа в Compose-файле и восстановите данные только после анализа причины. Не удаляйте каталоги meshcentral-data и meshcentral-files командой docker compose down -v: это может уничтожить данные Docker volume, если схема хранения была изменена.

Мониторинг

Проверяйте доступность HTTPS с внешнего узла, срок действия сертификата, свободное место и перезапуски контейнеров. Минимальный контроль можно реализовать cron-проверкой curl и уведомлением по электронной почте или в корпоративный чат.

# Смотрим загрузку ресурсов контейнеров
sudo docker stats --no-stream

# Проверяем место на диске
df -h / /opt/meshcentral

# Ищем ошибки в журнале за последние 30 минут
sudo journalctl --since "30 minutes ago" | grep -Ei "error|failed|meshcentral"

9. Troubleshooting и FAQ

Почему открывается ошибка 502 Bad Gateway?

Проверьте, запущен ли контейнер MeshCentral: sudo docker compose ps. Затем посмотрите его журнал командой sudo docker logs meshcentral. Если контейнер завершился, частые причины — ошибка JSON в config.json, неверный путь volume или неподдерживаемый параметр конфигурации. Проверьте синтаксис: jq . /opt/meshcentral/meshcentral-data/config.json. Также убедитесь, что Caddy и MeshCentral находятся в одной Docker-сети.

Сертификат Let’s Encrypt не выпускается. Что проверить?

Убедитесь, что A-запись домена указывает на текущий IPv4 VPS, а TCP 80 и 443 разрешены и в UFW, и во внешнем firewall провайдера. Проверьте DNS командой dig +short mesh.example.com, затем откройте логи sudo docker logs meshcentral-caddy. Если включена неправильная AAAA-запись, Let’s Encrypt может обращаться по IPv6 и попадать не на тот сервер. Удалите ошибочную запись или корректно настройте IPv6.

Агент установлен, но устройство не появляется в MeshCentral

На клиенте проверьте исходящий доступ к https://mesh.example.com и отсутствие корпоративного прокси, который блокирует WebSocket. Убедитесь, что дата и время на клиенте корректны, а установщик скачан именно из нужной группы MeshCentral. На Windows проверьте службу Mesh Agent и события системы, на Linux — статус службы через systemd. Если устройство было зарегистрировано на старом сервере, удалите старую установку агента и установите новый пакет приглашения.

Работает терминал, но нет удалённого рабочего стола

На Windows проверьте, запущена ли графическая сессия и разрешён ли доступ агенту. В Linux наличие GUI, X11/Wayland и прав пользователя влияет на работу desktop-сессии. В macOS отдельно выдаются разрешения Accessibility и Screen Recording в настройках приватности. Также проверьте, не отключена ли функция рабочего стола политикой группы. Терминал может работать независимо от графической сессии, поэтому его успешный запуск не гарантирует доступ к экрану.

Удалённый экран тормозит или разрывается

Измерьте задержку между оператором и клиентом, проверьте загрузку CPU и сетевой трафик контейнера. На качество влияют Wi-Fi, мобильные сети, VPN и параллельные передачи файлов. Завершите ненужные сессии, снизьте качество изображения и отключите передачу больших файлов во время интерактивной работы. Если одновременно используются десятки desktop-сессий, увеличьте VPS до 4–8 vCPU и 8–16 ГБ RAM, а также проверьте сетевой лимит.

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

Для лаборатории или нескольких компьютеров достаточно 1 vCPU, 2 ГБ RAM и 25 ГБ SSD, но такой запас не рассчитан на сотню устройств. Практический минимум для 100 агентов — 2 vCPU, 4 ГБ RAM, 40 ГБ SSD и стабильный канал от 100 Мбит/с. Если планируются одновременные удалённые рабочие столы, лучше выбрать 4 vCPU и 8 ГБ RAM. Обязательно нужен публичный адрес и доступные TCP 80/443.

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

Для ста машин и небольшого числа операторов выбирайте VPS: он дешевле, проще масштабируется и обычно имеет достаточно ресурсов. Dedicated нужен при сотнях или тысячах агентов, большой нагрузке на передачу файлов, строгой изоляции CPU, особых требованиях к дискам или сетевым интерфейсам. Начните с VPS с мониторингом и заранее подготовленным планом миграции. При росте нагрузки можно перенести Docker-стек и каталоги данных на dedicated.

Можно ли закрыть порт 80 после получения сертификата?

Оставлять TCP 80 открытым обычно удобно: Caddy использует его для HTTP-01-проверок и перенаправления пользователей на HTTPS. Если политика безопасности требует закрыть порт 80, настройте DNS-01-проверку через DNS-провайдера и убедитесь, что сертификат будет автоматически продлеваться. Простое закрытие 80 без изменения способа проверки может привести к остановке автоматического продления. Порт 443 должен оставаться доступным для агентов и операторов.

Как ограничить доступ оператора только к отдельным компьютерам?

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

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

На VPS развёрнут self-hosted MeshCentral с HTTPS, удалённым терминалом, рабочим столом, передачей файлов и управлением группами устройств. Для сотни машин достаточно умеренной конфигурации, если ограничить права пользователей, регулярно обновлять сервер и хранить зашифрованные резервные копии вне VPS.

1. Создайте тестовую группу из нескольких компьютеров, проверьте политики доступа и восстановление из бэкапа.
2. Добавьте внешний мониторинг HTTPS, свободного места, срока TLS-сертификата и состояния контейнеров.
3. При росте нагрузки разделите MeshCentral, резервное хранилище и дополнительные сервисы по отдельным узлам либо перенесите установку на dedicated-сервер.