MeshCentral en municipios: soporte remoto, grupos y corte
Mini-caso para soporte municipal con agentes, escritorio remoto, terminal, archivos, PostgreSQL, permisos, 2FA y prueba de baja.
Una sesión remota quedó autorizada después de cambiar el proveedor de soporte. El equipo seguía apareciendo en la mesa técnica y nadie sabía si podía abrir escritorio, terminal o archivos. MeshCentral 1.2.4 permite administrar dispositivos desde un servidor web propio. Este caso muestra cómo ordenar grupos, agentes, permisos y corte de acceso en un municipio del Gran Mendoza.
Dónde aparece el soporte con acceso viejo
El caso empieza con veinte puestos: mesa de entradas, rentas, catastro, tránsito y un depósito. Soporte necesita entrar a equipos dispersos, pero cada área maneja datos distintos. El antagonista es el acceso heredado: una cuenta de proveedor queda viva, un equipo se mueve de oficina y la sesión remota sigue disponible. El repositorio Ylianst/MeshCentral registraba 7.027 estrellas, 942 forks y licencia Apache-2.0 al momento de esta corrida. La release 1.2.4 fue publicada el 22 de julio de 2026. El paquete oficial en npm exige Node.js 20 o superior y describe a MeshCentral como servidor web para administración remota de computadoras. El costo escondido no está en abrir una pantalla; está en dejar permisos vivos cuando cambia una guardia o un contrato. El sitio oficial de MeshCentral resume el alcance: gestión remota de dispositivos, servidor y agente multiplataforma para Windows, Linux, macOS y FreeBSD. Sus palabras clave de npm incluyen escritorio remoto, terminal remoto, acceso a archivos, KVM, 2FA e Intel AMT. Esa lista conviene leerla como inventario de riesgo, no como menú para habilitar todo.
Cómo funciona por dentro
El flujo arranca con el servidor MeshCentral en una red controlada. Sistemas crea grupos por área y define quién puede ver, conectar, transferir archivos o ejecutar terminal. Cada puesto instala MeshAgent, que registra el dispositivo contra el servidor. El agente queda asociado a un grupo y reporta disponibilidad; cuando soporte inicia sesión, la aplicación valida usuario, permiso y equipo. 1. Sistemas crea grupos: mesa de entradas, rentas, catastro y soporte externo. 2. Cada equipo instala agente y queda identificado por nombre y grupo. 3. MeshCentral muestra estado, escritorio, terminal y archivos según permisos. 4. PostgreSQL puede guardar usuarios, dispositivos, grupos y eventos del servidor. 5. 2FA reduce el riesgo de contraseña reutilizada. 6. El responsable de área aprueba altas, bajas y cambios de grupo. 7. El backup copia base, configuración, certificados y archivos; la restauración abre un equipo de prueba. La guía de quickstart instala con npm dentro de un directorio dedicado y arranca con node node_modules/meshcentral. La documentación de agentes lista rutas de instalación y control en Windows, Linux/BSD y macOS. La guía de PostgreSQL muestra la sección settings.postgres con host, puerto, usuario, contraseña y base.
Qué se instala o configura primero
El primer entregable verificable son cinco equipos de ensayo, tres grupos, dos perfiles de soporte y una baja documentada. El servidor corre con usuario de bajo privilegio, proxy HTTPS, 2FA obligatorio para administradores, PostgreSQL externo y respaldo diario. La guía de instalación segura recomienda ejecutar el servicio con una cuenta dedicada y restringida; también advierte que ese modo obliga a actualizaciones manuales y base externa. Con dólar oficial vendedor a ARS 1520, un piloto de 18 a 32 horas técnicas a USD 30/h queda entre USD 540 y USD 960, es decir entre ARS 820.800 y ARS 1.459.200. Una instancia con respaldo puede moverse entre USD 40 y USD 100 mensuales, entre ARS 60.800 y ARS 152.000. Incluye servidor, certificados, cinco agentes, grupos, permisos, 2FA, backup y restauración. Quedan fuera mesa de ayuda completa, inventario patrimonial y soporte fuera de horario. UMSA puede aplicar este patrón cuando un municipio, cooperativa o cámara necesita soporte remoto sin entregar credenciales permanentes a terceros. La primera decisión técnica es separar ayuda ocasional de administración: quien mira pantalla no debería tener terminal si el caso solo requiere orientar a un usuario. El cierre también debe probar una sesión aprobada por el área y otra rechazada por falta de permiso.
Dónde se rompe y cómo probarlo
El primer riesgo es proveedor sin baja. La señal aparece cuando una cuenta externa conserva acceso después de terminar el contrato. La prueba crea un usuario temporal, abre una sesión de ensayo, revoca cuenta y confirma rechazo desde otro navegador. El segundo riesgo es equipo en grupo incorrecto. La señal aparece cuando soporte de una oficina ve equipos de otra área. La prueba mueve un agente entre grupos y verifica que desaparezca para usuarios sin permiso. El tercer riesgo es servidor restaurado sin certificados. La señal aparece cuando agentes no vuelven a conectar o el navegador advierte una identidad distinta. La prueba restaura configuración, base y certificados en una instancia aislada, valida un equipo de prueba y registra el tiempo de recuperación. El acta debe incluir fecha, responsable y captura del equipo conectado; sin esa evidencia, el respaldo existe pero la operación sigue sin prueba. El soporte remoto sirve cuando cada sesión tiene usuario, permiso, motivo y cierre. El corte de acceso debe ser tan visible como la conexión.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.