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 із зовнішнього вузла, термін дії сертифіката, вільне місце та перезапуски контейнерів. Мінімальний контроль можна реалізувати перевіркою curl через cron і сповіщенням електронною поштою або в корпоративний чат.

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

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

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

9. Усунення несправностей і 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-сервер.