Home Assistant

Servidor de domótica, corriendo en Docker en pop-os (a diferencia del resto de Personal Hub, que vive en vm-playground — ver Docker). La razón de estar en una máquina local y no en la nube es de red: Home Assistant necesita descubrir y controlar dispositivos IoT en la LAN de casa (mDNS, SSDP, Zigbee/Z-Wave por USB), algo que un VM remoto no puede hacer.

docker-compose.yml en ~/proyectos/smart-home/, imagen oficial ghcr.io/home-assistant/home-assistant:stable, con network_mode: host (necesario para el descubrimiento de dispositivos, no por el motivo de hairpin NAT documentado en Docker para los servicios de vm-playground) y privileged: true + bind mount de /run/dbus (recomendación oficial de la imagen para acceso a hardware/Bluetooth).

Config persistida en ~/proyectos/smart-home/homeassistant-config/.

trusted_proxies obligatorio

Sin esto, HA responde 400: Bad Request (texto plano, viene del propio HA, no de Cloudflare) a cualquier request que llegue por el túnel — es la protección incorporada contra Host header no confiable. Hace falta en configuration.yaml:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - ::1

cloudflared conecta a localhost:8123 desde el propio host (network_mode: host), así que el origen del request para HA siempre es 127.0.0.1/::1 — sin declarar esas IPs como proxies confiables, HA no distingue esto de un ataque de DNS rebinding.

Acceso externo

Expuesto en home.estebanalcocer.cloud vía un túnel de Cloudflare dedicado (smart-home-t640-pop, id 29f6d085-6921-442a-9174-6e6dda957427) — pop-os no tenía ningún túnel corriendo antes de este servicio, así que es uno nuevo en vez de sumarse al túnel de vm-playground. Corre como servicio systemd (cloudflared.service), config en /etc/cloudflared/config.yml.

Véase también

• Docker — patrón general, aunque este servicio corre en un host distinto
• Túneles de Cloudflare — el otro túnel activo, en vm-playground
• NetBird — cómo se accede a pop-os desde otros dispositivos de Esteban