MeshCentral en un VPS: acceso remoto gratuito a un centenar de máquinas

6. Instalación del software — paso a paso

Instalación de Docker Engine

En lugar de utilizar paquetes de repositorios aleatorios, use el repositorio apt oficial de Docker. En 2026, Docker Engine 27+ y Compose Plugin 2.x son adecuados para Ubuntu Server 24.04. La versión secundaria concreta dependerá del repositorio actual.

# Удаляем конфликтующие старые пакеты, если они есть
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

Añadir el usuario al grupo docker resulta práctico, pero este grupo proporciona de facto permisos de root a través del socket de Docker. Para un VPS independiente pequeño, puede utilizar sudo docker sin ampliar los permisos del usuario.

Creación de directorios del proyecto

# Создаём каталоги 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

Archivo de variables de entorno

Guarde los secretos y el nombre de dominio en el archivo .env, no en un archivo YAML que pueda enviarse accidentalmente a Git con mayor facilidad. El archivo solo debe estar disponible para su propietario.

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

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

Docker Compose

El proyecto oficial de MeshCentral publica la imagen del contenedor en el registro GitHub Container Registry. La etiqueta latest resulta práctica para el primer inicio, pero en un entorno de producción es preferible fijar una etiqueta verificada después de probar la actualización. El ejemplo siguiente utiliza la imagen ghcr.io/ylianst/meshcentral:latest; antes de actualizar, compruebe las etiquetas compatibles en el repositorio oficial del proyecto.

# Создаём 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 escucha dentro de la red de Docker en el puerto 4433. No es necesario publicar este puerto externamente: el único punto de entrada externo será Caddy en los puertos TCP 80 y 443.

7. Configuración

Configuración de MeshCentral

Cree el archivo config.json en el directorio de datos. El valor WANonly activa el modo de servidor para dispositivos remotos. El parámetro webProxy permite que MeshCentral funcione correctamente detrás de un proxy inverso, mientras que AliasPort define el puerto HTTPS externo que ven los agentes.

# Создаём конфигурацию 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

El valor newAccounts: false desactiva el registro abierto. Normalmente, el primer administrador se crea a través de la interfaz web durante el primer inicio, si el contenedor utiliza el mecanismo estándar de MeshCentral. Después de crear el administrador, compruebe que el registro público esté realmente cerrado.

Los parámetros pueden variar entre versiones de MeshCentral. Si una versión concreta ignora un campo o informa de un error, compárelo con el ejemplo de configuración actualizado de la documentación oficial y con el registro del contenedor. No copie parámetros desconocidos sin verificarlos: algunos ajustes afectan a la compatibilidad de los agentes.

Proxy inverso Caddy

Caddy obtiene y renueva automáticamente el certificado de Let’s Encrypt. Para emitir correctamente el certificado, el DNS ya debe apuntar al VPS y los puertos TCP 80 y 443 deben estar accesibles desde Internet.

# Создаём конфигурацию 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

En algunas versiones de MeshCentral, el servidor HTTPS interno utiliza un certificado autofirmado. Por ello, en el bloque transport http se especifica tls_insecure_skip_verify. Esta conexión se realiza únicamente dentro de la red de Docker; el TLS externo termina en Caddy. No utilice este parámetro para crear un proxy de un servicio externo arbitrario.

Comprobación de DNS, TLS y 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

El resultado esperado es una respuesta HTTP 200 o una redirección a la página de inicio de sesión. Un error 502 significa que Caddy no puede conectarse a MeshCentral. Un error de certificado suele estar relacionado con el DNS, el puerto 80 cerrado o una hora incorrecta en el servidor.

Primer inicio de sesión y creación de un grupo

Abra https://mesh.example.com en el navegador. Cree una frase de contraseña larga de al menos 14 caracteres y active la autenticación de dos factores TOTP en el perfil de usuario, si esta función está disponible en la versión instalada.

Cree grupos independientes: por ejemplo, «Oficina», «PC domésticos», «Clientes» y «Servidores». No conceda al operador acceso a todo el servidor si solo necesita un grupo. Utilice una cuenta independiente para cada empleado, de modo que las acciones queden registradas.

Instalación de MeshAgent en los equipos cliente

En la interfaz de MeshCentral, abra el grupo de dispositivos necesario y seleccione la opción para añadir un equipo. Descargue el instalador del agente correspondiente al sistema operativo y entréguelo al usuario mediante un canal seguro o distribúyalo a través de un sistema de gestión existente.

En Windows, el agente se instala como servicio con privilegios de administrador. En Linux se requiere acceso root, mientras que en macOS se necesitan permisos de Accessibility y Screen Recording. Sin estos permisos, el agente puede conectarse, pero el escritorio remoto y el control de entrada estarán limitados.

Para instalaciones masivas, no inserte tokens de invitación en scripts públicos. Utilice políticas de grupo, Intune, Ansible, Salt, un RMM existente u otro mecanismo interno de distribución. Después de la instalación, compruebe que el agente aparezca en el grupo correcto y tenga los permisos esperados.

Comprobación de la sesión remota

1. Asegúrese de que el dispositivo aparezca como conectado.
2. Abra la información del dispositivo y compruebe el nombre del sistema operativo, la dirección IP y la hora del último contacto.
3. Inicie el terminal y ejecute un comando seguro, por ejemplo whoami o hostname.
4. Compruebe la transferencia de un archivo de texto pequeño.
5. Abra el escritorio y finalice la sesión con el botón correspondiente.
6. Compruebe el registro de acciones del administrador.

Comprobación del reinicio y el inicio automático

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

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

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

8. Copias de seguridad y mantenimiento

Qué es necesario conservar

El directorio meshcentral-data es crítico. Contiene la configuración, la base de datos, las claves del servidor, los certificados y el estado de los dispositivos. Si se pierden las claves o la base de datos, los agentes pueden requerir un nuevo registro y los usuarios y grupos dejarán de estar disponibles.

El directorio meshcentral-files contiene los archivos de los usuarios y los datos relacionados con la transferencia de archivos. Los directorios de Caddy /opt/caddy/data y /opt/caddy/config almacenan los certificados y los datos de servicio del proxy. También es obligatorio realizar copias del archivo Compose, Caddyfile y .env, pero los secretos que contengan deben estar cifrados.

Instalación de Restic

Restic cifra los datos antes de enviarlos a un almacenamiento compatible con S3. A continuación se muestra un ejemplo con variables de entorno. Los valores de las claves no deben colocarse en un script abierto ni pasarse en la línea de comandos, donde podrían aparecer en la lista de procesos.

# Устанавливаем 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

Genere una contraseña independiente para el repositorio de al menos 32 caracteres aleatorios y guárdela en un gestor de contraseñas. Perder la contraseña de Restic significa perder la posibilidad de descifrar el archivo.

Script de copia de seguridad automática

# Создаём скрипт резервного копирования
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

Para ejecutarlo diariamente, cree un temporizador de systemd o un cron. La opción con cron es más sencilla, pero systemd resulta más cómodo para el registro.

# Добавляем ежедневный запуск в 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'

Prueba de restauración

Una copia de seguridad que nunca se ha restaurado no puede considerarse verificada. Una vez por trimestre, cree un directorio temporal y extraiga allí la última copia. No sustituya el directorio de trabajo antes de comprobar el contenido y la compatibilidad de las versiones.

# Восстанавливаем последний снимок во временный каталог
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

Actualización de MeshCentral y Docker

No actualice automáticamente la instalación de producción cada noche. Primero estudie los cambios de la versión, realice una copia de seguridad completa y después actualice la imagen durante una ventana de mantenimiento planificada. Para un centenar de agentes, es mejor probar primero la actualización en un grupo de prueba independiente compuesto por varias máquinas.

# Сохраняем текущие версии и делаем резервную копию
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

Si la nueva versión es incompatible, restaure la etiqueta de imagen anterior en el archivo Compose y restaure los datos solo después de analizar la causa. No elimine los directorios meshcentral-data y meshcentral-files con el comando docker compose down -v: esto puede destruir los datos del volumen de Docker si se ha modificado el esquema de almacenamiento.

Supervisión

Compruebe la disponibilidad de HTTPS desde un nodo externo, la validez del certificado, el espacio libre y los reinicios de los contenedores. El control mínimo puede implementarse mediante una comprobación de curl con cron y notificaciones por correo electrónico o en el chat corporativo.

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

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

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

9. Solución de problemas y FAQ

¿Por qué aparece el error 502 Bad Gateway?

Compruebe si el contenedor MeshCentral está en ejecución: sudo docker compose ps. Después, consulte su registro con el comando sudo docker logs meshcentral. Si el contenedor se ha detenido, las causas frecuentes son un error JSON en config.json, una ruta de volume incorrecta o un parámetro de configuración no compatible. Compruebe la sintaxis: jq . /opt/meshcentral/meshcentral-data/config.json. Asegúrese también de que Caddy y MeshCentral se encuentren en la misma red de Docker.

El certificado de Let’s Encrypt no se emite. ¿Qué debo comprobar?

Asegúrese de que el registro A del dominio apunta a la dirección IPv4 actual del VPS y de que TCP 80 y 443 están permitidos tanto en UFW como en el firewall externo del proveedor. Compruebe el DNS con el comando dig +short mesh.example.com y, a continuación, abra los registros sudo docker logs meshcentral-caddy. Si hay un registro AAAA incorrecto, Let’s Encrypt puede acceder mediante IPv6 y llegar a otro servidor. Elimine el registro erróneo o configure IPv6 correctamente.

El agente está instalado, pero el dispositivo no aparece en MeshCentral

En el cliente, compruebe el acceso saliente a https://mesh.example.com y la ausencia de un proxy corporativo que bloquee WebSocket. Asegúrese de que la fecha y la hora del cliente sean correctas y de que el instalador se haya descargado exactamente del grupo de MeshCentral necesario. En Windows, compruebe el servicio Mesh Agent y los eventos del sistema; en Linux, el estado del servicio mediante systemd. Si el dispositivo se registró en un servidor antiguo, elimine la instalación anterior del agente e instale el nuevo paquete de invitación.

El terminal funciona, pero no hay escritorio remoto

En Windows, compruebe si la sesión gráfica está iniciada y si el acceso del agente está permitido. En Linux, la presencia de GUI, X11/Wayland y los permisos del usuario influyen en el funcionamiento de la sesión de escritorio. En macOS, los permisos Accessibility y Screen Recording se conceden por separado en la configuración de privacidad. Compruebe también que la función de escritorio no esté desactivada por una política de grupo. El terminal puede funcionar independientemente de la sesión gráfica, por lo que su ejecución correcta no garantiza el acceso a la pantalla.

La pantalla remota funciona lentamente o se desconecta

Mida la latencia entre el operador y el cliente, y compruebe el uso de CPU y el tráfico de red del contenedor. La calidad se ve afectada por Wi-Fi, las redes móviles, VPN y las transferencias de archivos simultáneas. Finalice las sesiones innecesarias, reduzca la calidad de imagen y desactive la transferencia de archivos grandes durante el trabajo interactivo. Si se utilizan simultáneamente decenas de sesiones de escritorio, aumente el VPS a 4–8 vCPU y 8–16 GB de RAM, y compruebe también el límite de red.

¿Qué configuración mínima de VPS será adecuada?

Para un laboratorio o varios equipos, son suficientes 1 vCPU, 2 GB de RAM y 25 GB de SSD, pero esta reserva no está diseñada para un centenar de dispositivos. El mínimo práctico para 100 agentes es 2 vCPU, 4 GB de RAM, 40 GB de SSD y un canal estable de al menos 100 Mbit/s. Si se prevén escritorios remotos simultáneos, es preferible elegir 4 vCPU y 8 GB de RAM. Es imprescindible disponer de una dirección pública y de acceso a TCP 80/443.

¿Qué elegir: VPS o dedicated para esta tarea?

Para cien máquinas y un número reducido de operadores, elija un VPS: es más barato, escala con mayor facilidad y normalmente dispone de recursos suficientes. Se necesita un dedicated cuando hay cientos o miles de agentes, una gran carga de transferencia de archivos, una estricta aislación de CPU, requisitos especiales para los discos o las interfaces de red. Comience con un VPS con monitorización y un plan de migración preparado de antemano. A medida que aumente la carga, puede trasladar la pila de Docker y los directorios de datos a un dedicated.

¿Se puede cerrar el puerto 80 después de obtener el certificado?

Normalmente es conveniente mantener TCP 80 abierto: Caddy lo utiliza para las comprobaciones HTTP-01 y para redirigir a los usuarios a HTTPS. Si la política de seguridad exige cerrar el puerto 80, configure la comprobación DNS-01 mediante el proveedor de DNS y asegúrese de que el certificado se renueve automáticamente. Cerrar simplemente el puerto 80 sin cambiar el método de comprobación puede provocar que se detenga la renovación automática. El puerto 443 debe seguir siendo accesible para los agentes y operadores.

¿Cómo limitar el acceso del operador solo a determinados equipos?

Cree un grupo de dispositivos independiente y asigne al operador permisos únicamente para ese grupo. No utilice una única cuenta compartida para todo el equipo: de lo contrario, no será posible determinar de forma fiable quién inició el terminal o transfirió un archivo. Desactive las funciones que el operador concreto no necesite, como la transferencia de archivos o el terminal remoto. Revise periódicamente la lista de usuarios, los tokens de invitación y los registros de acciones, especialmente después de la baja de un empleado o del cambio de contratista.

10. Conclusiones y próximos pasos

En el VPS se ha implementado un MeshCentral self-hosted con HTTPS, terminal remoto, escritorio, transferencia de archivos y gestión de grupos de dispositivos. Para un centenar de máquinas es suficiente una configuración moderada si se limitan los permisos de los usuarios, se actualiza periódicamente el servidor y se almacenan copias de seguridad cifradas fuera del VPS.

1. Cree un grupo de prueba con varios equipos y compruebe las políticas de acceso y la restauración desde la copia de seguridad.
2. Añada monitorización externa de HTTPS, del espacio libre, de la validez del certificado TLS y del estado de los contenedores.
3. Cuando aumente la carga, distribuya MeshCentral, el almacenamiento de copias de seguridad y los servicios adicionales en nodos independientes, o traslade la instalación a un servidor dedicated.