Volver al blog

Monitorización de dispositivos en la red interna del cliente mediante un agente LAN

· 7 min de lectura

En resumen La monitorización en la nube no alcanza a los dispositivos de la red interna del cliente - NAS, cámaras, servidores locales, impresoras. El agente LAN de ePulz.io resuelve esto con un modelo pull: un pequeño demonio en tu red llama a ePulz.io a través de HTTPS habitual, recibe una lista de IP a comprobar, las pingea localmente y envía los resultados de vuelta. Sin redirección de puertos, sin VPN, sin puertos abiertos desde fuera.

El problema: la nube no ve hacia dentro

La monitorización de uptime clásica corre en un centro de datos. Funciona genial para webs públicas - una petición HTTP de Frankfurt a tu hosting y de vuelta. El problema empieza en el momento en que quieres monitorizar algo que no se ve desde fuera:

  • Un NAS con copias de seguridad (192.168.1.10)
  • Grafana / Prometheus / Jira interna en 10.0.0.50:3000
  • Cámaras IP en la tienda, gateways IoT, impresoras de red
  • Un router o switch del que quieres saber cuándo cae
  • Gateway VPN, servidor RADIUS, DNS local

Las soluciones habituales vienen con concesiones incómodas:

  • Redirección de puertos - abres un puerto público en el router, la monitorización se conecta por la IP pública. Pesadilla de seguridad, a menudo contra la política corporativa.
  • Túnel VPN entre la monitorización y la red del cliente - funciona, pero requiere configuración del lado de IT, configuración estática de peer y mantenimiento.
  • Cron en el servidor del cliente que pingea la monitorización - un heartbeat. Funciona, pero solo dice que el agente vive, no si un objetivo concreto de la red es alcanzable.

La solución: un agente con modelo pull

El agente LAN de ePulz.io invierte la dirección de la comunicación. En vez de que el servidor se cuele en la red del cliente, un demonio simple en la red del cliente contacta el servidor por sí mismo. El principio:

  1. Cada 30 segundos el agente pregunta: "¿Qué monitores tengo que comprobar ahora?"
  2. El servidor devuelve una lista (por ejemplo: ping 192.168.1.10 cada minuto, TCP 192.168.1.50:5432 cada 5 minutos).
  3. El agente ejecuta las comprobaciones locales (ICMP ping, TCP connect, HTTP GET).
  4. El agente envía los resultados de vuelta por la misma conexión HTTPS.
  5. En cambio de estado (UP → DOWN o vuelta) ePulz.io dispara la notificación estándar - email, Telegram o webhook.

Toda la comunicación va por HTTPS saliente en el puerto 443. El mismo puerto que tu router tiene abierto para el navegador. Sin redirecciones, sin tráfico entrante, sin VPN.

Tres tipos de comprobaciones LAN

Tipo Objetivo Caso de uso
lan_ping 192.168.1.10 El dispositivo de la red está vivo (eco ICMP). Comprobación más barata, ve el RTT con precisión sub-milisegundo.
lan_tcp 10.0.0.50:5432 Un puerto concreto responde (DB, SSH, SMTP, RDP). Detecta cuando el proceso cae aunque el host siga corriendo.
lan_http http://nas.local La interfaz web funciona (HTTP 2xx/3xx). GUI del NAS, panel interno, API local.

Instalación: dos variantes

Para un servidor Linux con acceso root (Raspberry Pi, mini PC, VM de la red):

sudo bash <(curl -s https://epulz.io/install-agent.sh) plzag_xxx

El script instala el agente en /opt/epulzio-agent y lo registra como servicio systemd. Arranca solo después de reboot.

Para hosts Synology / Unraid / k3s / Docker:

docker run -d --name epulzio-agent --restart unless-stopped \
  --network host \
  -e EPULZIO_AGENT_TOKEN=plzag_xxx \
  epulzio/agent

--network host es importante - el agente necesita acceso a la red local del host.

Qué pasa cuando el agente se queda mudo

Este es un escenario frecuentemente olvidado en setups caseros: el agente deja de funcionar (red, corte de luz, kernel panic), el monitor se queda para siempre en "last_status: up" y nadie se entera. ePulz.io lo resuelve con lógica de heartbeat aparte:

  • Cada petición exitosa del agente actualiza last_seen.
  • Un scheduler comprueba los agentes activos cada minuto. Si last_seen es más antiguo que 5 minutos, sale email y mensaje de Telegram: "El agente LAN X está offline".
  • Cuando el agente vuelve, recibes notificación de back-online.

Gracias a esto nunca acabarás en el estado "todo se ve verde porque no se está midiendo nada".

Seguridad

  • Autenticación por token: el agente autentica vía X-Agent-Token: plzag_…. Solo guardamos el hash SHA-256 en la BD; el token en claro lo ves una vez al crearlo.
  • Revoca en cualquier momento desde el dashboard. Tras revocar el agente recibe HTTP 401 y deja de aceptar tareas.
  • Rate limit por agente: 120 peticiones por minuto. Protege el servidor de agentes en bucle o defectuosos.
  • Sin credenciales directamente en el script: el token vive en /opt/epulzio-agent/agent.env con permisos 0600.

Cuándo no necesitas agente LAN

Si solo monitorizas webs públicas, APIs y certificados SSL, las sondas cloud clásicas de ePulz.io te bastan. El agente LAN tiene sentido cuando:

  • Gestionas varios clientes y quieres ofrecer monitorización de sus sistemas internos.
  • Tienes arquitectura híbrida (parte cloud, parte on-prem) y quieres un panel de estado unificado.
  • Necesitas mediciones de RTT sub-milisegundo en la LAN, imposibles de conseguir por internet.

Empezar

El agente LAN está disponible en todos los planes incluyendo periodo de prueba. La instalación lleva tres minutos:

  1. Crea un agente en dashboard → agentes LAN.
  2. Copia el token (se muestra una sola vez).
  3. Ejecuta el instalador en una máquina de la red del cliente.
  4. Añade un monitor LAN vía "Añadir nuevo monitor" y elige tipo lan_ping, lan_tcp o lan_http.

Pruébalo gratis

7 días de acceso completo incluyendo agentes LAN. Sin tarjeta. Sin renovación automática.

Crear cuenta →

Prueba ePulz.io gratis - 7 días sin tarjeta de crédito.

Crear cuenta