Monitoreo de homelab sin abrir puertos ni exponer el NAS

En pocas palabras: OpsHome NOC monitorea un homelab sin port forwarding mediante Docker Probe, un conector que corre dentro de la LAN y se conecta por HTTPS saliente a la nube, chequeando servicios HTTP, HTTPS y TCP internos —NAS, Proxmox, Docker— sin exponer ninguna interfaz a internet.

Si alguna vez armaste un homelab con Proxmox, un NAS y media docena de contenedores Docker, sabés que un check público que dice “todo verde” no garantiza nada. OpsHome NOC incluye Docker Probe, un componente que corre dentro de tu LAN, se conecta por HTTPS saliente a la nube y chequea servicios internos sin abrir puertos ni exponer tu Proxmox o tu Synology a internet.

El monitoreo de homelab es el seguimiento del estado de servidores, contenedores Docker, NAS y apps autohospedadas dentro de una red privada, sin exponerlos a internet. OpsHome NOC, de OpsHome, combina checks públicos de sitios y APIs con Docker Probe, un conector que corre dentro de la LAN y reporta a la nube por conexión saliente, evitando el port forwarding y el riesgo de abrir interfaces de administración.

¿Por qué el monitoreo de homelab no alcanza si solo mirás desde afuera?

Un check público exitoso solo confirma que un endpoint responde desde afuera. No te dice si Proxmox, tu NAS Synology o los contenedores que corren adentro de la LAN están sanos.

Ejemplo hipotético: imaginá que tenés un reverse proxy exponiendo tu app de notas a internet. El check público va a decir “online” aunque el backend que vive en una VM de Proxmox esté con el storage al 95% y a punto de colapsar. El check externo mide la puerta de entrada, no lo que pasa del otro lado. Según la publicación técnica de OpsHome, “un chequeo público exitoso no significa que tus apps e infraestructura internas estén sanas, y abrir interfaces de administración solo para que un sistema externo las monitoree crea riesgo de seguridad”.

¿Y entonces qué hacés, abrís el puerto del NAS igual porque “es solo para monitorear”? Ese es justo el error que la fuente marca como riesgo. Cada interfaz de gestión que exponés a internet (aunque sea “solo para leer estado”) es una superficie de ataque más: si alguien encuentra una vulnerabilidad en esa interfaz, no le importa que vos la hayas abierto “solo para ver un semáforo verde”.

¿Qué es el Docker Probe y cómo evita el port forwarding?

Docker Probe es el componente privado de OpsHome NOC que corre en un host Docker de tu red y se conecta hacia afuera, no al revés. Se despliega con un docker compose up -d generado desde la app, usando la imagen oficial opshomenoc/opshome-noc:latest publicada en Docker Hub, según la guía de instalación de Docker Probe.

La lógica de fondo es la misma que usa cualquier conexión saliente en una red doméstica: cuando el Probe abre la conexión HTTPS hacia OpsHome Cloud, el router y el firewall ya saben que ese tráfico de respuesta es parte de una conexión que vos iniciaste, así que lo dejan pasar sin necesidad de reglas nuevas. Nadie “entra” desde afuera; es tu red la que sale a buscar a la nube. Por eso no hace falta tocar el router, no hace falta IP pública fija y no hace falta exponer ningún servicio interno a internet solo para que la nube lo vea.

Subís el Probe, lo verificás en la sección “Docker Probes” de la app, confirmás que esté online y a partir de ahí agregás los monitores privados que necesites. Si se queda offline, la documentación recomienda revisar logs con docker logs opshome-probe y la conectividad saliente antes de sumar más chequeos.

¿Qué servicios puede chequear el Docker Probe dentro de la LAN?

El Probe chequea servicios HTTP, HTTPS y TCP internos, reporta estado y eventos de contenedores Docker, y recolecta datos de infraestructura vía integraciones como Proxmox VE y Synology NAS. Todo desde adentro de la red, sin que el servicio target necesite salir a internet. Si te interesa el debate de fondo, ya lo tratamos en esta nota sobre self-hosting frente a un servicio de monitoreo administrado.

Según la documentación de Private Monitors, los casos típicos de target privado son algo así:

• HTTP para dashboards internos: paneles y APIs locales que corren sin TLS dentro de una LAN de confianza, por ejemplo http://192.168.50.20:5000.
• HTTPS para interfaces con certificado: paneles de NAS o la interfaz web de Proxmox, como https://192.168.50.30:8006.
• TCP para reachability básica: puertos como SSH (tcp://192.168.50.40:22) donde no hace falta una respuesta HTTP, solo saber si el puerto responde.
• Estado de contenedores Docker: si un contenedor reinició, entró en estado anormal o se cayó.
• Infraestructura vía integraciones: nodos, VMs y storage de Proxmox VE; sistema, recursos y discos de un NAS Synology según versión de DSM.

Las fallas más comunes, según la misma documentación, son target inalcanzable desde el host del Probe, scheme o puerto mal configurado, un firewall o VLAN bloqueando el camino, o un servicio que solo escucha en localhost. Nada exótico, son los mismos dolores de cabeza de siempre, solo que ahora los ves en un dashboard en vez de enterarte cuando el servicio ya está caído hace tres horas.

Criterio práctico para elegir el tipo de check: si el servicio responde a una URL y te interesa saber además si devuelve un error de aplicación (un 500, por ejemplo), usá HTTP o HTTPS. Si solo necesitás confirmar que algo escucha en un puerto —un SSH, una base de datos sin endpoint web propio— un chequeo TCP alcanza y es más liviano. No tiene sentido montar un check HTTPS contra algo que ni siquiera habla HTTP.

¿Qué recomendaciones de seguridad da OpsHome para instalar el Probe?

OpsHome recomienda montar el Docker Socket en modo solo lectura y usar cuentas o tokens de API con privilegios mínimos para integraciones como Proxmox y Synology. Nada de usar la cuenta admin de siempre para todo.

Esto no es un detalle menor. El Docker Socket montado en modo lectura-escritura le da a quien lo controle la capacidad de crear, modificar o eliminar contenedores en tu host, que es exactamente lo que no querés delegarle a un componente de monitoreo. Lo mismo con los tokens: un token de Proxmox con permisos de administrador total es una llave maestra que, si se filtra, compromete todo el clúster. Un token scoped solo a lectura de métricas es, en cambio, bastante menos peligroso si algo sale mal.

La documentación también sugiere pinning de digest como opción (no obligación) para quien quiera controlar exactamente qué versión de imagen corre, actualizando el digest manualmente en cada upgrade. Para la mayoría de los homelabs, seguir el :latest oficial alcanza; el pinning tiene sentido sobre todo si ya tenés un proceso de control de cambios y querés decidir vos cuándo pasa cada actualización, no si recién estás arrancando con esto.

¿Cuándo conviene sumar más de un Probe?

El monitoreo público y los Probes privados se complementan dando visión externa e interna de la misma infraestructura, bajo una sola cuenta. Podés correr Probes en distintos lugares (casa, oficina, un server room) y verlos todos juntos en un panel, ya que la plataforma soporta despliegue distribuido mientras las instancias pertenezcan a la misma cuenta.

Ahora bien, no todo homelab necesita más de un Probe. Un criterio simple para decidir:

• Un solo Probe alcanza si toda tu infraestructura vive en una única red física (una casa, una oficina chica) y no necesitás ver el servicio desde una ubicación geográfica distinta.
• Conviene sumar un segundo Probe cuando administrás redes separadas que no se ven entre sí —por ejemplo, un NAS en tu casa y un servidor de archivos en una oficina— y querés un solo panel para ambas en vez de dos monitoreos independientes.
• Un Probe en una red externa a la tuya tiene sentido puntualmente si necesitás además una vista “desde afuera” de tu propia infraestructura, complementaria al check público, pero para la mayoría de los homelabs esto es más la excepción que la regla.

La idea de fondo es que sumar Probes no debería ser un objetivo en sí mismo, sino una respuesta a una necesidad concreta: redes separadas que hoy monitoreás por separado, o puntos ciegos que un solo Probe no puede cubrir.

¿Dónde se ve esta información y qué no resuelve OpsHome NOC?

OpsHome NOC se ve desde tres lugares: la app de iPhone para operar, el Web Console (de solo lectura) para pantallas grandes, y las Status Pages para mostrarle a terceros si un servicio está caído. Lo que no hace es reemplazar herramientas de análisis de logs, observabilidad o gestión de infraestructura.

El Web Console usa el mismo inicio de sesión Apple que la app (Sign in with Apple) y, según la fuente, “OpsHome nunca recibe ni almacena tu contraseña de cuenta Apple”. Es útil para un wall display en la oficina, pero no reemplaza las consolas de administración de Proxmox, VMware, Synology o Docker: solo mira, no toca nada.

La app es gratis en la App Store (requiere iOS 17.6 o superior) y el monitoreo básico funciona sin suscripción. El plan Free cubre 30 monitores públicos, el Pro sube a 100 por USD 2,99/mes (o USD 24,99/año) y el Studio llega a 250 por USD 5,99/mes (o USD 49,99/año), según el detalle de planes publicado en el anuncio. Para un homelab chico con un puñado de servicios, el plan Free probablemente te alcanza sin necesidad de pagar nada; el salto a Pro o Studio tiene sentido cuando ya pasaste la treintena de endpoints públicos a monitorear, no antes.

Errores comunes al monitorear un homelab desde adentro

• Abrir el puerto del NAS o de Proxmox “solo para monitorear”: es exactamente el riesgo que un Probe con conexión saliente evita. Si ya hiciste esto, el primer paso es cerrarlo y migrar a un Probe interno.
• Montar el Docker Socket en lectura-escritura por comodidad: le das al componente de monitoreo la capacidad de modificar contenedores que no necesita tocar. Montalo read-only.
• Usar una sola credencial admin para todas las integraciones: un token de Proxmox o Synology con permisos totales es un punto único de falla. Tokens scoped por integración, con el mínimo privilegio necesario.
• Confundir el Web Console con una herramienta de gestión: es de solo lectura por diseño. Si necesitás reiniciar una VM o un contenedor, eso se hace en la consola nativa de Proxmox o Docker, no ahí.

Preguntas Frecuentes

¿Qué es el Docker Probe de OpsHome NOC?

Es un componente que se instala en un host Docker dentro de tu red privada y se conecta por HTTPS saliente a OpsHome Cloud. Permite chequear servicios HTTP, HTTPS y TCP internos, además de reportar estado de contenedores, sin requerir puertos entrantes abiertos.

¿Necesito abrir puertos para monitorear servicios internos?

No. El Docker Probe inicia la conexión hacia la nube, así que no requiere inbound port forwarding ni IP pública. Es la diferencia clave frente a exponer una interfaz de administración directamente a internet.

¿Qué pasa si el Probe se cae o no conecta?

Si el Probe queda offline, la documentación recomienda revisar los logs con docker logs opshome-probe y verificar la conectividad saliente HTTPS antes de agregar nuevos monitores. Mientras esté offline, los chequeos privados asociados a ese Probe no se ejecutan.

¿Cuánto cuesta OpsHome NOC?

La app es gratis y el monitoreo básico funciona sin suscripción ni tarjeta de crédito. El plan Pro cuesta USD 2,99/mes (100 monitores públicos) y el Studio USD 5,99/mes (250 monitores públicos), según los precios publicados en octubre de 2026.

¿OpsHome NOC reemplaza herramientas de observabilidad?

No. La propia documentación aclara que no reemplaza el análisis de logs, las plataformas de métricas ni el tracing distribuido, y tampoco sustituye la segmentación de red ni la gestión de credenciales. Es una capa de monitoreo y estado encima de lo que ya tenés corriendo.

Conclusión

Lo que cambia con OpsHome NOC v1.16 no es que inventaron el monitoreo de homelab (eso ya existía con mil herramientas self-hosted), sino que resuelven el problema específico de monitorear desde la nube sin abrir un solo puerto. Si tenés servicios internos que hoy chequeás a ojo, o peor, que expusiste a internet “solo para verlos desde afuera”, instalar un Docker Probe con permisos mínimos es un cambio chico que cierra un riesgo real. Antes de sumar integraciones de Proxmox o Synology, revisá que cada token tenga el mínimo privilegio necesario, y antes de sumar un segundo o tercer Probe, preguntate si de verdad administrás redes separadas o si es solo por sumar: es la diferencia entre un componente de monitoreo útil y una puerta trasera sin querer.

Fuentes

• Monitoring your homelab from inside the LAN – dev.to, artículo sobre OpsHome NOC v1.16 (octubre de 2026)
• Install Docker Probe – documentación oficial de instalación
• Private HTTP, HTTPS and TCP Monitors – documentación de monitores privados
• OpsHome Docs – hub de documentación de productos OpsHome
• OpsHome NOC – sitio oficial del producto