Redes de Home Assistant: cómo el descubrimiento, el DNS y el enrutamiento permiten la accesibilidad

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

La accesibilidad de Home Assistant solo existe cuando el descubrimiento o la configuración identifica un endpoint, el DNS resuelve direcciones utilizables y el enrutamiento, junto con las políticas, entrega los paquetes.

Es fácil agrupar estas funciones bajo una sola idea llamada red. En la práctica, un dispositivo puede aparecer en el descubrimiento mientras su puerto de servicio está bloqueado, o un nombre de host puede resolverse correctamente mientras ninguna ruta devuelve el tráfico. Tratar la ruta como una serie de capas hace que los fallos sean observables y evita que una comprobación exitosa certifique toda la conexión.

La accesibilidad es una cadena de condiciones independientes

Un intercambio funcional con Home Assistant necesita un identificador, una dirección, una ruta de ida, un servicio permitido y una ruta de vuelta. El descubrimiento puede proporcionar las primeras pistas, mientras que el DNS, el enrutamiento, el estado del firewall y el proceso de destino aportan condiciones diferentes. El fallo de cualquier enlace necesario produce un endpoint inaccesible, aunque todos los demás enlaces funcionen.

Las implementaciones segmentadas de Home Assistant hacen visible esta cadena porque cada límite debe atravesarse deliberadamente. Un informe práctico sobre redes de Home Assistant entre VLAN separa el descubrimiento multicast, las reglas del firewall entre VLAN y la exposición del contenedor, en lugar de tratarlos como un único interruptor.

Comienza el diagnóstico nombrando el origen y el destino exactos, el protocolo, el puerto y la familia de direcciones. Un navegador del panel que llega a Home Assistant sigue una ruta distinta de la que usa Home Assistant para llegar a un dispositivo IoT. La cadena debe evaluarse en la dirección de la transacción real, incluida la respuesta.

El descubrimiento encuentra servicios solo dentro de su ámbito de visibilidad

Los protocolos de descubrimiento anuncian nombres, tipos y ubicaciones de servicios sin exigir al usuario que introduzca cada dirección. Las integraciones de Home Assistant suelen utilizar DNS multicast u otras difusiones similares para detectar dispositivos compatibles. Esos paquetes normalmente tienen un ámbito de enlace local, por lo que los routers no los reenvían como tráfico unicast ordinario entre subredes.

Por tanto, las redes con varias subredes necesitan un puente de descubrimiento explícito cuando el descubrimiento automático debe cruzar un límite. El análisis de arquitectura de redes pequeñas de APNIC señala que el descubrimiento de servicios mDNS entre subredes requiere un proxy o relay, y distingue los anuncios de enlace local del tráfico de datos enrutado.

Un reflector puede hacer visible un servicio sin hacerlo accesible. El anuncio puede cruzar mientras el tráfico TCP o UDP permanece bloqueado, o puede anunciar una dirección inutilizable desde la subred receptora. Que el descubrimiento sea satisfactorio responde qué existe, no si puede establecerse la sesión completa.

El DNS asigna nombres, pero no crea una ruta para los paquetes

El DNS convierte un nombre de host en una o más direcciones. Elimina la necesidad de recordar números cambiantes y puede proporcionar respuestas diferentes a clientes locales y remotos. Una respuesta correcta solo demuestra que el resolvedor proporcionó datos; no demuestra que la dirección elegida sea accesible, que haya un servicio escuchando o que esté permitido.

Los sistemas de nombres privados muestran claramente esta separación. La explicación de Tailscale sobre el comportamiento del DNS privado describe la asignación de nombres a direcciones y el DNS dividido, mientras que el enrutamiento sigue siendo una capacidad independiente que debe transportar el tráfico hasta el endpoint privado seleccionado.

Comprueba la respuesta desde el mismo cliente y la misma red donde se produce el fallo. Un teléfono con datos móviles puede utilizar un resolvedor diferente y recibir una dirección distinta de la de una tableta fijada a la pared y conectada por Wi-Fi. Inspecciona también IPv4 e IPv6 por separado, porque una dirección preferida pero inutilizable puede retrasar o impedir una conexión que, de otro modo, sería válida.

-15% OFF

El enrutamiento y las políticas del firewall deciden si los paquetes atraviesan la red

El enrutamiento selecciona el siguiente salto hacia la dirección resuelta, mientras que la política del firewall decide si se permite el tráfico. Un router puede conocer ambas subredes y aun así denegar el puerto del servicio, o permitir el tráfico saliente sin mantener el estado de retorno esperado. La accesibilidad requiere una ruta coherente de ida y de respuesta.

El acceso privado remoto expone la diferencia entre nombres y reenvío. Un informe práctico sobre el enrutamiento de subredes requiere una ruta anunciada y el reenvío de IP antes de que los clientes remotos puedan llegar a dispositivos LAN normales, aunque los nodos de la red superpuesta ya tengan nombres e identidades.

Utiliza reglas de mínimo privilegio basadas en el flujo real, en lugar de abrir VLAN completas. Permite el origen, el destino, el protocolo y el puerto necesarios, y confirma después que las respuestas siguen una ruta válida. Los firewalls con estado simplifican muchos flujos de retorno, pero las rutas asimétricas o las subredes superpuestas aún pueden producir accesibilidad en un solo sentido.

Las redes de contenedores cambian lo que Home Assistant puede ver

Un contenedor tiene su propio espacio de nombres de red, salvo que comparta la red del host. Las redes en modo puente añaden traducción de direcciones, interfaces virtuales y puertos publicados entre Home Assistant y la LAN física. Estos límites pueden filtrar el multicast o anunciar una dirección interna que los pares no pueden utilizar.

El efecto aparece en instalaciones reales donde el acceso web normal funciona, pero fallan las integraciones que dependen de difusiones. Un informe de un operador sobre los límites del descubrimiento en redes puente describe integraciones de Apple TV que no reciben difusiones, aunque el contenedor siga siendo accesible.

Las redes del host reducen los límites de traducción y multicast, pero amplían la exposición directa del proceso a las interfaces del host. Macvlan o un relay explícito pueden conservar la separación y cambiar al mismo tiempo el comportamiento del descubrimiento. Elige el modelo cuya ruta de paquetes puedas documentar y prueba después las integraciones necesarias, en lugar de asumir que un modo es universalmente más seguro.

El descubrimiento puede tener éxito y aun así terminar en un fallo de sesión

El límite de fallo más evidente se produce cuando un dispositivo es visible por nombre, pero inutilizable en Home Assistant. El anuncio puede contener una dirección obsoleta, la dirección resuelta puede apuntar a la interfaz equivocada, el servicio puede escuchar solo en localhost o un firewall puede rechazar el puerto anunciado. El descubrimiento ha cumplido su función a pesar del fallo de la sesión.

Las implementaciones de Matter y Thread muestran cuántos límites pueden coexistir. Una implementación multisubred de descubrimiento de Home Assistant entre VLAN combina enrutamiento, reglas de firewall, incorporación desde otra subred y un router fronterizo, lo que demuestra por qué una observación multicast satisfactoria no puede certificar el intercambio unicast posterior.

También ocurre lo contrario: la configuración manual llega a un dispositivo cuyos anuncios de descubrimiento nunca atraviesan la subred. Ese resultado demuestra que la ruta del servicio enrutado funciona, mientras que el descubrimiento no. Mantén separados estos resultados para no utilizar un reflector como solución a un puerto bloqueado ni un cambio en el firewall como solución a una respuesta DNS incorrecta.

Ejecuta una prueba de la ruta de paquetes en cinco saltos

Realiza la prueba desde el host exacto de Home Assistant o desde el cliente que inicia la transacción fallida. Primero captura el servicio descubierto o el destino configurado. Después resuelve su nombre de host y registra todas las direcciones devueltas. A continuación, inspecciona la ruta seleccionada para esa dirección. Luego prueba el puerto del servicio. Por último, confirma la respuesta y el protocolo de enlace de la aplicación.

Las evidencias de la ruta de paquetes son más sólidas cuando cada capa se observa de forma independiente. La guía sobre las redes de contenedores de Home Assistant explica por qué suele elegirse el modo host para el tráfico multicast y de difusión, y ofrece un punto de comparación concreto para los fallos relacionados con espacios de nombres.

Registra aprobado o fallido para el descubrimiento, la resolución, la ruta, la política y el protocolo de enlace, en lugar de escribir únicamente «inaccesible». Compara el resultado con la guía de decisión de ZimaSpace sobre redes host frente a redes puente. Cambia la primera capa que falle y vuelve a ejecutar los cinco saltos, porque una ruta reparada puede revelar el siguiente límite.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.