Home Assistant funciona con Wi-Fi, pero falla con Ethernet o VPN

Cuando Home Assistant funciona por Wi‑Fi pero falla por Ethernet o VPN, es probable que la aplicación esté sana; el problema suele estar en el estado del enlace, el direccionamiento, las rutas, las políticas, el DNS, el tráfico de retorno o la detección multicast.

Mantén disponible la ruta Wi‑Fi conocida como funcional mientras pruebas Ethernet y VPN por separado. Primero usa la IP directa de la interfaz de destino; después verifica la puerta de enlace y la ruta de retorno; luego prueba el puerto del servicio, el nombre de host y la detección. Cambiar varias capas de red a la vez puede dejarte fuera del sistema y hace imposible atribuir un resultado satisfactorio a una causa concreta.

Demuestra que la interfaz Ethernet tiene una dirección utilizable

Comprueba el enlace físico, la velocidad negociada, el estado de la interfaz, la dirección asignada, la subred, la puerta de enlace y la concesión DHCP desde el host de Home Assistant o el hipervisor. Compáralos con los de un cliente funcional en la misma red Ethernet. Las luces del enlace por sí solas no demuestran que la configuración de capa 3 sea correcta.

Un caso de la comunidad recomienda inspeccionar todas las interfaces con nmcli cuando no aparecía el dispositivo eth0 esperado. La primera prueba útil es comprobar el nombre y la dirección reales de la interfaz, en lugar de asumir que todas las plataformas llaman eth0 a su puerto cableado.

Desde un cliente de la misma subred, haz ping o prueba de cualquier otra forma la IP de Ethernet y el puerto 8123 abierto directamente. Si no se puede acceder a la IP, continúa con las comprobaciones del enlace, la VLAN, DHCP y la subred. Si la IP funciona pero falla el nombre de host, el servicio Ethernet está sano y el DNS se convierte en la siguiente línea de investigación.

Comprueba la selección de rutas, la política del cortafuegos y el tráfico de retorno

Inspecciona la tabla de enrutamiento mientras Wi‑Fi y Ethernet están activos. Identifica la ruta predeterminada, las métricas de las interfaces y la ruta de regreso al cliente de prueba o a la subred VPN. Las respuestas que salen por la interfaz equivocada pueden hacer que las conexiones entrantes parezcan bloqueadas incluso cuando la solicitud ha llegado.

Prueba temporalmente desde la misma VLAN antes de atravesar las políticas del router. Si el acceso dentro de la misma subred funciona pero el acceso enrutado falla, inspecciona las reglas del cortafuegos entre VLAN, el modo de red del contenedor, el puente del hipervisor, las redes permitidas de la VPN y la ruta inversa en el lado de Home Assistant.

La comparación de ZimaSpace entre la red en modo host y en modo puente ayuda a distinguir un límite del puerto del contenedor o de la detección de un fallo físico de Ethernet. Conserva la ruta Wi‑Fi funcional hasta que la ruta cableada supere la prueba de forma independiente.

Separa la accesibilidad directa del DNS y la detección

Haz las pruebas en este orden: IP de Ethernet o VPN, puerto del servicio, nombre de host configurado y, por último, detección automática. Si la IP directa funciona pero falla el nombre de host, el problema apunta al DNS o a una dirección almacenada en caché que está obsoleta. Si la interfaz web funciona directamente pero faltan dispositivos, el problema apunta a la detección o a la política de la subred de los dispositivos.

Los debates sobre Home Assistant entre subredes muestran que la resolución mDNS puede fallar incluso cuando se permite el tráfico unicast normal, porque la detección multicast necesita un reenvío deliberado o un reflector. Esta distinción entre multicast y unicast es especialmente importante en VLAN y VPN enrutadas.

No amplíes todas las reglas del cortafuegos para hacer que aparezca la detección. Prefiere direcciones explícitas de integración cuando sean compatibles o configura un relay multicast con un alcance limitado entre segmentos de confianza. Si no se puede acceder a la propia interfaz web mediante la IP directa, la detección todavía no es la reparación relevante.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Aplica una sola corrección de red y vuelve a probar todas las rutas

Corrige únicamente la capa confirmada: el cable o el puerto del switch, la reserva DHCP, la subred o la puerta de enlace, la métrica de la interfaz, la regla del cortafuegos, la ruta de retorno, el registro DNS, la red permitida de la VPN o el relay multicast. Guarda la configuración anterior y prepara un método de acceso local antes de reiniciar los servicios de red.

Vuelve a probar la IP de Ethernet, el nombre de host, los dispositivos locales, el cliente VPN, la interfaz web remota, la estabilidad de WebSocket y la detección en el mismo orden. Reinicia el host una vez y renueva el estado de red del cliente para que las rutas y el DNS obsoletos no produzcan un éxito temporal.

Un resultado satisfactorio conserva un acceso Ethernet fiable, mantiene la ruta VPN prevista, evita rutas predeterminadas duplicadas y detecta dispositivos únicamente a través de límites aprobados. Revierte los cambios si desaparece la ruta Wi‑Fi funcional o si se filtra tráfico entre segmentos; escala el problema aportando pruebas de la interfaz, las rutas, el cortafuegos y el flujo de paquetes cuando las solicitudes llegan pero las respuestas siguen saliendo de forma incorrecta.