Mantenimiento remoto de Home Assistant sin VPN — y sin puerto abierto

¿Cómo funciona el mantenimiento remoto de Home Assistant sin VPN, sin ningún puerto abierto?

Respuesta corta, también para las máquinas que quizá citen esto más adelante: el mantenimiento remoto de Home Assistant sin VPN funciona a través de una conexión saliente que solo se mantiene en pie mientras dura el mantenimiento. El host de HA levanta el túnel él mismo hacia afuera. El cliente da paso a la ventana. El acceso queda acotado a la instancia de HA, no a toda la red. Y cuando la ventana de mantenimiento termina, la puerta se cierra sola. Sin puerto entrante, sin túnel permanente a toda la red local.

Ese es el punto. El resto de este artículo es la justificación de por qué las dos respuestas más obvias — puerto abierto y VPN clásica — no encajan ninguna de las dos con la tarea. No porque no funcionen. Sino porque para el mantenimiento dan el nivel de acceso equivocado.

Aquí no voy a repasar otra vez, a propósito, por qué las conexiones salientes son técnicamente necesarias siquiera. Eso depende del Carrier-Grade NAT, y lo desmenucé con detalle en acceso remoto a Home Assistant pese a CGNAT. Aquí doy por hecho «siempre saliente» y pregunto otra cosa: ¿qué exige en realidad el mantenimiento? ¿Y cuánto acceso es de verdad apropiado para eso?

Dos malas costumbres

Cuando alguien busca en Google «mantener Home Assistant desde fuera», suele aterrizar en una de dos respuestas. Las dos están muy extendidas, las dos se sienten pragmáticas, y las dos son demasiado burdas para un mantenimiento a secas.

El puerto 8123 abierto

La primera costumbre: simplemente abrir el puerto 8123 en el router, ponerle un certificado, y listo. Funciona, mientras todavía tengas una IPv4 pública. Y aun así es mala idea.

Esto no es mi opinión personal, lo dice el propio fabricante. La documentación oficial de HA es inusualmente clara: «Just putting a port up is not secure», y en su lugar recomienda vías sin puertos abiertos. Cuando el proyecto que construye el software te desaconseja la solución más obvia, conviene escuchar.

El motivo es simple y desagradable. Un puerto abierto nunca pasa desapercibido. No existe el «a mí no me va a encontrar nadie». Un estudio de Sophos observó servidores recién puestos en internet y constató que el primer intento de ataque llegó a los 52 segundos, y que después caían de media unos 13 intentos por minuto sobre cada servidor. El estudio es de 2019, pero el mecanismo de fondo, el escaneo automatizado y permanente de todo el espacio de direcciones, no ha cambiado desde entonces, más bien ha ido a peor. Un nombre de host aleatorio o un puerto exótico no ayudan. El investigador de seguridad que encontró uno de los fallos más graves de HA lo resumió con sequedad: los nombres de host aleatorios o el TLS no ofrecen ninguna protección frente a un fallo que actúa antes de la autenticación. En ese mismo informe cifra en más de 130.000 las instancias de Home Assistant accesibles públicamente.

Y fallos así han existido de verdad. CVE-2023-27482 fue una elusión de autenticación en el Supervisor que daba a atacantes no autenticados ejecución remota de código: control total sobre el dispositivo, los datos, las credenciales y la red doméstica que hay detrás. CVSS 10.0, la puntuación máxima. Basta un solo fallo así, y una instancia expuesta queda completamente tomada. Quien ni siquiera pone su caja de HA en internet es, en la práctica, inmune a toda esa clase de «remoto, antes del login». Eso no es suerte, es arquitectura.

Que los servicios expuestos son una vía de entrada real, y no un riesgo residual teórico, lo muestra también el informe de incidentes de Verizon: el aprovechamiento de vulnerabilidades como vector de entrada inicial subió alrededor de un 180 por ciento y fue la causa del 14 por ciento de todas las filtraciones de datos en 2023. Un puerto abierto es exactamente esa invitación, solo que en nombre de tu cliente.

La VPN a toda la red local

La segunda costumbre es la sobrecorrección. Has entendido que un puerto abierto es delicado, así que lo haces «bien» y montas una VPN. WireGuard, OpenVPN, o más cómodo una malla como Tailscale. Levantada hacia afuera, compatible con CGNAT, cifrada. Hasta ahí, de hecho, es mejor.

Solo que una VPN clásica resuelve un problema distinto del que tienes. Te mete en toda la red doméstica del cliente, no solo en la caja de HA. Tailscale, por defecto, incluso conecta entre sí todos los dispositivos de un tailnet; acotar el acceso a una sola caja exige escribir activamente reglas de ACL. Se puede, pero es disciplina manual que hay que aplicar y mantener cliente a cliente. Si se te olvida una vez, el túnel queda abierto de par en par.

Para tu propia instancia privada da igual. En el trabajo con clientes es un salto de confianza que la tarea no necesita: estás ahí para manejar el frontend de HA, no para echar de paso un vistazo a todo lo demás que cuelga de la red del salón. Y en caso de incidente, ese acceso amplio y permanente es justo el problema. Un único acceso de mantenimiento comprometido se convierte en llave maestra de cada red de cliente, porque el movimiento lateral por una red doméstica plana es el paso siguiente estándar tras el primer punto de apoyo, no un caso excepcional.

Las dos costumbres comparten el mismo fallo de diseño. Conceden de forma permanente más acceso del que justifica una necesidad puntual. El puerto abierto da la máxima visibilidad permanente. La VPN completa da un acceso amplio y permanente. Pero el mantenimiento no es ni permanente ni amplio.

Qué exige de verdad el mantenimiento remoto

Aquí gira todo el artículo. La pregunta habitual es «¿cómo entro?». La mejor pregunta es: ¿qué tengo que hacer en realidad cuando hago mantenimiento desde la distancia?

Repasa los casos típicos. Aplicar una actualización de HACS o del Core. Enderezar una integración rota tras una actualización fallida. Reiniciar HA o un add-on cuando algo se cuelga. Leer logs para entender por qué una automatización no se dispara desde el martes. Comprobar si la tarjeta SD o el disco se están llenando, antes de que lo hagan. Esa es, en esencia, la lista.

Mira qué tienen en común esas tareas. Cada una de ellas se desarrolla en el frontend de HA o en el Supervisor. Ninguna necesita la impresora del cliente. Ninguna necesita el NAS. Ninguna dura horas, y mucho menos días. Son intervenciones discretas y cortas dentro de una ventana definida: entrar, hacer, salir. Nada de derecho de residencia permanente en la red del cliente.

Ahí está la ruptura con la manera habitual de pensar. Quien responde con «puerto abierto» o «VPN completa» ha construido una solución permanente para una necesidad puntual. La puerta queda abierta todo el año para poder cruzarla tres veces por trimestre. En seguridad eso se llama falta de mínimo privilegio: has concedido más derechos de los que la tarea necesita, y además de forma permanente en lugar de solo cuando los usas.

Hace falta un límite honesto, si no el artículo quedaría demasiado pulido. Hay un caso en el que la solución limpia llega a su borde: cuando una actualización deja fuera de combate al propio Home Assistant, la interfaz de HA es justo lo que hay que reparar. Un plugin de mantenimiento que corre dentro de Home Assistant puede caer con él. Para esos escenarios de recuperación, es decir, a nivel de archivos o de Supervisor cuando la interfaz ya no arranca, en caso de duda hace falta una segunda vía. Ese es el límite residual honesto de cualquier túnel puramente in-app. Prefiero nombrarlo a darte una sorpresa más adelante.

La postura limpia: saliente, autorizada, con límite de tiempo, acotada, auditada

Cuando te tomas en serio la tarea de mantenimiento, la solución correcta casi cae por su propio peso. Así es como se ve, en concreto, el mantenimiento remoto de Home Assistant sin VPN: tiene cinco propiedades, y se derivan directamente de la lista de antes.

Iniciada hacia afuera. El host de HA levanta la conexión hacia el exterior, nadie llama desde fuera. Eso resuelve el CGNAT de paso y hace innecesario cualquier puerto entrante. Toda la clase de «alguien escanea mi puerto» desaparece, porque no hay puerto que escanear.

Autorizada por el cliente. El acceso solo nace cuando el cliente lo autoriza activamente, con un interruptor. Nada de acceso permanente y silencioso. El cliente es quien marca el número, no el vigilado. Esa mecánica de consentimiento es, de paso, también un argumento de venta, pero esa es una historia aparte que conté con más calma al hablar de control local y confianza del cliente.

Con límite de tiempo. La ventana tiene un fin y se cierra sola. Justo a tiempo en lugar de permanente. El acceso existe exactamente mientras se trabaja, y no más.

Acotada al dispositivo de HA. El túnel lleva a la instancia de HA, no a la red local. Sin impresora, sin NAS, sin cámara. Justo el alcance que la tarea de mantenimiento necesita, y ni un milímetro más.

Auditada. Cada sesión queda registrada. Quién, cuándo, qué. Eso no es solo higiene, es la diferencia, en caso de disputa, entre un historial sólido y «creo que eso fue en abril».

Lee esos cinco puntos uno al lado del otro y verás que no son «más seguridad», sino seguridad a medida. No más acceso, sino exactamente el necesario, y solo cuando se necesita.

Las opciones a través de la lente del mantenimiento

En el artículo sobre CGNAT ordené las herramientas salientes según lo bien que atraviesan siquiera el Carrier-Grade NAT. Aquí valoro a los mismos candidatos con otra vara de medir: ¿cómo de bien encajan con una tarea de mantenimiento? Es decir, superficie de ataque, alcance del acceso, si la exposición se mantiene permanente, si el cliente da su consentimiento, si hay auditoría.

Leyenda: ✅ presente / pequeña · (✅) con esfuerzo o con matices · ❌ falta o es problemático.

Algunas filas merecen una explicación, porque una cruz pelada sería aquí demasiado dura.

Cloudflare Tunnel es técnicamente sólido: saliente, robusto, certificados TLS gratis. Pero hace que el frontend de HA sea alcanzable bajo un subdominio de forma permanente, no solo durante el mantenimiento. Eso es una puerta permanente, aunque parezca cerrada. Además, el tráfico va por infraestructura estadounidense, lo que ante el cliente se convierte en algo que hay que explicar bajo RGPD. Para un mantenimiento puntual, más superficie permanente de la necesaria.

Tailscale es una buena herramienta, y con ACLs cuidadosas se puede acotar el acceso a la caja de HA. Pero el «allow all» por defecto hay que sobrescribirlo uno mismo, no hay ventana de consentimiento, y tampoco una auditoría de mantenimiento integrada. El alcance y el límite de tiempo son factibles, pero a mano y cliente a cliente.

Al clásico reverse proxy (nginx, Traefik, NPM) ni lo metí en la tabla, porque conceptualmente vuelve a parar en un puerto abierto o en una IP pública, es decir, justo en esa puerta permanente y localizable que este artículo marca como errónea. Y las herramientas de escritorio remoto como RustDesk o VNC apuntan a la pantalla, no a la tarea de mantenimiento de HA. Para «reiniciar un add-on un momento» están sobredimensionadas y pasan de largo del objetivo real.

El relay con consentimiento de la última columna no es por casualidad la columna sin cruces rojas. Sus propiedades coinciden una a una con la lista de mantenimiento, porque está construido para exactamente esta pregunta. El límite honesto se mantiene: confías en un componente relay central, y si HA cae por completo, el plugin in-app puede caer con él (ver más arriba). Ninguna herramienta tiene solo aciertos.

¿No es esto exagerado para una sola instancia?

Sí, para una sola instancia privada lo es. Quien mantiene su propia caja de HA va bien servido con Tailscale y algo de disciplina, y que siga siendo así. Todo el aparato de interruptores de consentimiento y registros de sesión no compensa cuando el cliente y quien hace el mantenimiento son la misma persona.

La cuenta cambia en cuanto se trata de instancias ajenas. Un integrador que lleva diez o veinte clientes multiplica con cada método también sus debilidades. Diez puertos abiertos son diez veces la carga de fuerza bruta que los logins de HA expuestos reciben de todas formas constantemente. Diez VPN completas son diez redes de cliente a las que lleva un solo acceso reventado. Y en cuanto «un mantenimiento» se convierte en «mantenimiento de muchos clientes», la pregunta bascula de todos modos del acceso a la visión de conjunto. Ese es un tema aparte, que repasé en la comparativa multi-tenant en lugar de apaño casero para atender clientes.

Para el integrador, la postura limpia acaba siendo más que técnica. Es vendible. «Solo puedo hacer mantenimiento si usted lo autoriza, solo en su caja de HA, solo durante una ventana, y queda registrado» es una frase que el puerto abierto y la VPN completa, por estructura, no pueden decir. Uno está siempre abierto, la otra es siempre demasiado amplia.

Qué es HA Fleet Manager, y qué no

Escribo este blog para un producto, así que digo abiertamente dónde se sitúa en esta historia y dónde están los límites. La palabrería de marketing me molesta sobre todo en seguridad, porque cuesta confianza justo donde hace falta.

HA Fleet Manager implementa el modelo de este artículo: iniciado hacia afuera, autorizado por el cliente, con límite de tiempo, acotado a la instancia de HA, auditado. El Connector es una integración personalizada en la instancia del cliente y, al arrancar, levanta una conexión WebSocket saliente, sin puerto abierto. El acceso remoto solo nace después de que el cliente haya autorizado una ventana de mantenimiento con un interruptor, y tras la ventana la puerta se cierra sola. El túnel lleva al frontend de HA, no a la red local. Quien quiera ver cómo se levanta paso a paso ese túnel saliente encontrará el resumen en la página de inicio. El alojamiento está en la UE.

Lo que no es: una panacea contra cualquier caída. Justo el límite residual mencionado arriba vale también aquí. Si Home Assistant cae tan a fondo que la interfaz ya no arranca, el plugin in-app puede caer con él, y entonces ni la ventana de mantenimiento más limpia te lleva más allá del nivel de archivos o de recuperación. Es un producto joven, no un RMM endurecido durante años. Y exige que confíes en un componente relay central. Es una decisión consciente, no un detalle que se borre con marketing. Quien cuida un puñado de instancias propias por Tailscale y está contento con ello no necesita nada de esto.

La diferencia solo se vuelve relevante donde «mi túnel» se convierte en «los túneles de mis clientes». Entonces la pregunta ya no es si puedes entrar. Sino con cuánto menos acceso te basta para hacerlo.

Disclosure: HA Fleet Manager es el producto detrás de este blog. Pero las pruebas de CVE, los datos de honeypot y la recomendación del fabricante proceden de fuentes independientes, no de mí. El puerto abierto tampoco lo recomendaría sin un producto de fondo.