Acceso remoto a Home Assistant con DuckDNS y certificado SSL emitido por Let’s Encrypt

Vamos a configurar Home Assistant para poder ser accesible desde FUERA de nuestra red local, de forma completamente gratuita y segura, haciendo uso de DuckDNS y un certificado SSL emitido por Let’s Encrypt.

Aclaraciones previas

Home Assistant dispone de dos vías para ser accesible desde fuera de nuestra red local; la fácil y la difícil. Lógicamente, podríamos ir por la vía fácil pero esto implica una suscripción mensual a Nabu Casa. (PD: Nabu Casa es la empresa formada por los desarrolladores de Home Assistant y que sirve cómo vía de monetización del proyecto). Si uno no quiere complicarse la vida, Nabu Casa cuenta con un mes gratis de prueba y luego cuesta 5$ al mes; la implementación es inmediata, solo es necesario crear una cuenta, meter los detalles de pago y ya tendríamos acceso remoto. (Esta entrada no está patrocinada, así cómo dato).

Cómo por estos lares no somos amigos de las suscripciones mensuales, vamos a escoger la solución ‘difícil’ (pero gratuita) que también nos proporciona HASS mediante algunos add-ons oficiales: DuckDNS y DNSMasq.

Lista de componentes

• Nuestro sistema domótico con Home Assistant instalado en una Raspberry Pi, Intel NUC, etc.
• Nuestro ordenador desde el que trabajemos con conexión a internet.
• Preferiblemente una cuenta de Google (recomendable una que no sea nuestra cuenta «principal»), pero también podemos usar Twitter, Github o Persona.
• Acceso al panel de configuración de nuestro router (debe permitir añadir reglas de redirección).
• Una operadora de internet (ISP) que no haga uso de CGNAT (ahora comprobamos esto).
• Aproximadamente una hora de tiempo libre.

Comprobaciones y requisitos previos

Es recomendable leer todo ANTES de empezar a trastear, de lo contrario se corre el riesgo de hacer cambios difícilmente reversibles. Además, es enormemente recomendable hacer una copia de seguridad de nuestro sistema previamente, antes de empezar a modificar nada.

Debemos, y recalco, DEBEMOS, asegurarnos de que nuestra operadora (ISP) NO nos está asignando CGNAT. El CGNAT o Carrier-grade NAT es un tipo de NAT (mecanismo de traducción de direcciones) que permite a algunas operadoras configurar redes privadas que se traducen luego a redes públicas; la idea es que muchos clientes compartan conjuntos de direcciones (útil cuando hay pocas direcciones asignables), pero un incordio si queremos mantener un servidor o similar en nuestra red. Desgraciadamente si usamos CGNAT estas instrucciones NO SIRVEN y no podremos usar esta vía para el acceso remoto.

¿Y cómo puñetas se si uso CGNAT? En lugar de llamar a nuestra operadora podemos hacer una comprobación rápida desde la propia consola de Windows. Usando el comando tracert y haciendo una prueba a nuestra IP pública (podemos ver nuestra IP pública en cualquier servicio cómo WhatIsMyPublicIP), podemos medir el nº de saltos de la trama devuelta por tracert. Si la trama devuelve UN solo salto, podemos continuar, tenemos suerte.

tracert x.x.x.x

Si la trama devolviese más de un salto, estamos dentro de una red que emplea CGNAT y este tutorial no nos vale.

La siguiente cosa a tener en cuenta es el acceso a nuestro router; si estamos usando un router propio no tendremos casi seguro ningún problema, pero en el caso de que estemos usando el router de nuestra operadora, tenemos que asegurarnos que podemos:

• Acceder a su panel de configuración.
• Añadir reglas de redirección de puertos (port-forwarding).

Por lo general todas las puertas de enlace suelen estar en 192.168.1.1 pero ya que hemos abierto la consola, ejecutamos ipconfig y buscamos el campo dónde diga «Puerta de enlace predeterminada». Esa dirección nos lleva al router cuyas credenciales debemos tener apuntadas (normalmente, si no las hemos cambiado, que deberíamos hacerlo, estas aparecen debajo del router).

Una vez dentro del panel del router empiezan los problemas: cada router es un completo mundo distinto al anterior y existen infinidad de modelos de numerosas marcas, cada uno de ellos con paneles de configuración e interfaces distintas. Cómo es imposible hacer un tutorial específico para cada uno, lo recomendable es buscar aquella opción que se llame «Puertos», «Redireccionamiento», «Redirección de puertos» o «Port-forwarding». Existe una web llamada PortForward (que aunque está un poco anticuada) tiene guías para bastantes modelos de routers sobre cómo proceder.

Si nuestro router cuenta con alguna opción parecida a la de la siguiente imagen, aunque no lo vamos a tocar ahora mismo, ya sabemos que vamos bien encaminados. La razón detrás de esto, es que necesitamos exponer el puerto 8123 (por defecto en HASS) a internet si queremos acceder al sistema de forma remota.

Si cumplimos con los anteriores requisitos, podemos empezar a instalar los add-ons que vamos a utilizar. En este caso, desde Supervisor > Tienda de complementos (add-ons) > Duck DNS > Instalar; pero NO lo iniciemos todavía. También instalamos ya el complemento Dnsmasq y lo dejamos parado.

Necesidad de DuckDNS

¿Cuál es el sentido de usar DuckDNS? ¿No podemos usar la IP pública y ya? Por dar una explicación lo más corta posible: la IP pública que tenemos asignada es, con carácter general, dinámica; es decir, cambia cada cierto tiempo. Podemos pedir a nuestro ISP (proveedor de internet) que nos asigne una IP fija (y siendo así no necesitaríamos DuckDNS) peeeeero esto suele costar dinero en la mayoría de compañías telefónicas (mucho dinero).

¿La solución? Un servidor de nombres de dominio, un DNS. Esto en esencia es un sistema que asignará a nuestra IP un nombre reconocible (cómo thisisjustmadefortesting.duckdns.org), de forma que ‘traduce’ direcciones IP en nombres fáciles de tratar para las personas.

¿Pero si mi IP pública cambia, cómo soluciona esto el problema? Para ello existe el add-on de DuckDNS que vamos a utilizar; le va a indicar a nuestra cuenta de DuckDNS cuál es la IP constantemente de forma que nunca perdamos acceso ante un cambio de IP pública.

DuckDNS

DuckDNS es un proyecto gratuito de DNS (Sistema de nombres de dominio) hosteado en servidores de Amazon AWS. No es el servicio más rápido pero si es completamente gratuito. Si queremos convertir nuestra instancia de HASS en un servicio remoto, necesitamos un servidor DNS que nos lo permita.

Entramos en DuckDNS y aquí se nos presentan distintas opciones para crear una cuenta. Por simplicidad, recordemos que un servicio gratuito, no podemos registrarnos con el clásico email + contraseña así que tenemos que elegir acceder o bien con una cuenta de Google, Github, Twitter o Persona (Reddit era una opción hace tiempo pero ya no está disponible). Para esto recomiendo tener una cuenta secundaria de alguno de estos servicios.

Una vez hecho click en el botón que hayamos elegido, se nos presenta una página similar dónde crear nuestro nuevo dominio así cómo cierta información que necesitaremos: email y token.

Aquí vamos a introducir el nombre que le vamos a dar a nuestro dominio, esto es, la URL que vamos a usar para acceder a nuestro sistema así que conviene usar un nombre relativamente descriptivo pero tampoco demasiado simple; en mi caso, con fin temporal, voy a crear uno llamado dominiodeejemploparahass.duckdns.org y tras hacer click en el botón verde de «add domain» se nos presenta el dominio creado, nuestro token y dos campos: uno llamado «Current IP» y otro «IPv6».

Nos interesa el campo llamado «Current IP» dónde, cómo veremos, aparece nuestra IP pública (que ya conocemos de antes). Aunque este paso no es estrictamente necesario, vamos a cambiar esta IP por uno de los servidores DNS públicos de, por ejemplo, Google (8.8.8.8 ó 8.8.4.4) o Open DNS (208.67.222.222 ó 208.67.220.220), etc. En mi caso voy a poner 8.8.4.4 aunque el que tomemos no tiene relevancia ya que debe volver a cambiar luego.

Este paso no es obligatorio y el servidor DNS elegido es irrelevante, pero nos servirá para probar luego que todo está funcionando.

Port Forwarding

La redirección de puertos o port-forwarding es la forma en la que exponemos un puerto de un sistema en LAN al exterior. Cómo ya hemos comprobado que nuestro router lo permite, vamos a entrar de nuevo y añadir una regla de redireccionamiento TCP (¡OJO!; sólo TCP (Protocolo de control de transmisión), NO elegir UDP (Protocolo de datagrama de usuario) o TCP&UDP).

Cómo ya hemos dicho, cada router puede tener una interfaz distinta pero lo que queremos en definitiva es crear una regla (podemos darle el nombre que queramos), de tipo TCP que exponga la IP de nuestro sistema Home Assistant (¡OJO!, NO la IP de nuestro ordenador, la de la Raspberry, Intel NUC, etc.) al puerto 8123.

Si además de exponer HASS queremos hacer uso de sus integraciones con Google Assistant o similares debemos exponer el puerto 443 (WAN) al 8123 (tendríamos que añadir otra regla más), pero en mi caso no quiero hacer uso de asistentes virtuales cómo los de Google así que obviaré este puerto.

Configuración Add-on DuckDNS

¿Recuerdas el add-on que instalamos antes? Vale, pues ahora vamos a configurarlo: Supervisor > Duck DNS > Configuración y modificamos lo siguiente:

• Campo booleano de «accept_terms» de «lets_encrypt»: a true.
• Token: con el token que nos generó Duck DNS antes.
• Domains: añadimos -dominiodeejemploparahass.duckdns.org

lets_encrypt:
    accept_terms: true
    certfile: fullchain.pem
    keyfile: privkey.pem
token: my_secret_token
domains:
    - my_secret_domain.duckdns.org
aliases: []
seconds: 300

AVISO: La configuración del add-on se ha simplificado ligeramente, desde la pestaña Configuración, ahora hay dos campos para introducir directamente el dominio y el token. La opción de Alias no tenemos que tocarla y debajo tenemos un pequeño fragmento de código yaml correspondiente a Let’s Encrypt dónde solo debemos cambiar la opción accept_terms: por true.

Tras guardar los cambios, volvemos a la pestaña de Información del Add-on y pulsamos en «Iniciar» o «Start». Vamos rápidamente a la pestaña de «Registro» o «Logs» y refrescamos varias veces (con un poco de paciencia) hasta que veamos algún mensaje de OK. Por lo general deberíamos ver algún mensaje que nos diga «OK – Responding to challenge for …..» confirmando que la petición a nuestro dominio de Duck DNS ha sido satisfactoria.

Si queremos asegurarnos, para esto cambiamos antes la IP pública en la web de Duck DNS por 8.8.4.4. Si recargamos la página, deberíamos ver que la IP ha cambiado y vuelve a mostrar nuestra IP pública, esto es buena señal de que todo va cómo la seda.

Nótese que NO tenemos que instalar el add-on de Let’s Encrypt. Esto suele ser algo que mucha gente confunde. Este add-on está pensado para gestionar los certificados almacenados en nuestro sistema (dado que los certificados caducan y necesitan renovarse), pero precisamente el add-on de Duck DNS cuenta con campo llamado lets_encrypt, que al setear en «true» nos genera el certificado y se encarga el mismo (el add-on de Duck DNS) de renovarlo automáticamente.

Configuración Home Assistant

Al igual que el add-on, también tenemos que configurar el fichero configuration.yaml de nuestro sistema (¿no sabes de que hablo?, lo explico en este tutorial). O bien lo editamos desde nuestro ordenador o usamos alguna extensión cómo Visual Studio o File Editor para editar el fichero y añadimos el siguiente campo:

# Remote access
http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

Guardamos los cambios y si todo ha ido bien, vamos a Configuración > Controles del servidor > Verificar configuración y deberíamos recibir un mensaje de «¡Configuración válida!». Si es así, podemos reiniciar Home Assistant, de lo contrario, nos hemos equivocado en algún paso y tenemos que repasar.

Primer reinicio

Tras reiniciar es bastante posible que no volvamos a la misma página donde estábamos. La forma en que accedemos a nuestro sistema ha cambiado. Probamos a entrar cómo:

• https://IP_privada:8123
• https://nuestrodominio.duckdns.org:8123

Cualquiera de las dos debería funcionar (pero si una no funciona, probar la otra, con un poco de paciencia y asegurándonos de que usamos https y no http). Cuando entremos, vamos a encontrarnos con un aviso inicial, dado que estamos accediendo desde nuestra red interna y no desde fuera; dependiendo del navegador, haremos click en un lado u otro para acceder independientemente del aviso.

Unificar URLs de acceso y enmascaramiento

Vamos a cambiar correctamente la forma en que accedemos para no tener problemas de certificados inválidos o quedarnos sin acceso. Esto se puede modificar en el configuration.yaml pero cómo también puede editarse desde Lovelace vamos a Configuración > Configuración general > URL Externa/Interna. En estos dos campos, mi recomendación es escribir: «https://midominio.duckdns.org:8123» sin olvidarnos del puerto y el detalle del https que no http. Guardamos los cambios.

Ahora vamos a enmascarar la dirección o lo que es lo mismo, hacer que midominio.duckdns.org se traduzca a nuestra dirección privada (192.168.x.x) cuando accedemos a nuestro sistema desde nuestra red local. Con este fin instalamos al principio el add-on Dnsmasq. Vamos a Supervisor > Dnsmasq > Configuración y editamos:

• La lista hosts; añadiendo el host: midominio.duckdns.org
• El campo de IP asociado a dicho host, esto es, la IP privada de nuestro sistema HASS (192.168.x.x).
• Adicionalmente, podríamos modificar las DNS por defecto (que son las de Google) por las de otra operadora DNS pública (o por nuestro propio servidor DNS).

defaults:
    - 8.8.8.8
    - 8.8.4.4
forwards: []
hosts:
    - host: my_secret_domain.duckdns.org
      ip: 192.168.x.x
services: []

La configuración del add-on de Dnsmasq también se ha simplificado, desde Configuración ahora hay campos para rellenar la información más simples:

    # Bajo el campo de hosts:
    - host: my_secret_domain.duckdns.org
      ip: 192.168.x.x

Guardamos los cambios, arrancamos el add-on desde la pestaña de «Información». Esperamos unos minutos y comprobamos que todo ha ido bien desde Configuración > Controles del servidor > Verificar configuración y si todo ha ido bien, reiniciamos.

Si todo ha ido perfecto, deberemos poder acceder a nuestro sistema desde «https://midominio.duckdns.org» tanto desde dentro de nuestra red cómo desde fuera, con un certificado válido de Let’s Encrypt. Ahora podemos además, instalar la aplicación oficial de Home Assistant en cualquier dispositivo Android o Apple para acceder de forma remota y ver que pasa en nuestra casa.

Comprobaciones finales y recomendaciones

Ahora que estamos usando un certificado, es posible que tengamos que cambiar la configuración de algunos add-ons que ya veníamos usando antes y cuya opción SSL (Secure Sockets Layer) estará desactivada sin duda.

Por ejemplo, si teníamos instalado el add-on de Grafana (aquí explicamos cómo usar InfluxDB junto a Grafana), debemos ir a configuración del add-on y setear la variable «ssl» a «true», guardar y reiniciar el add-on. Repetiremos este paso para todos los add-ons que cuenten con esta opción. Así mismo, si la configuración especifica un valor para «certfile:» escribiremos «fullchain.pem» y si especifica «keyfile» escribiremos «privkey.pem».

plugins: []
env_vars: []
ssl: true
certfile: fullchain.pem
keyfile: privkey.pem

Por otro lado, es importante destacar la relevancia de una contraseña de acceso segura a nuestro sistema (recordad que puede cambiarse desde Configuración > Personas > Seleccionar nuestro usuario > Cambiar la contraseña). Además, es muy recomendado activar la verificación en dos pasos o autenticación de doble factor que nos requerirá de un código de acceso temporal además de la contraseña, para ello necesitaremos un móvil y una aplicación como Authy o Google Authenticator; vamos a nuestro usuario (el icono con la primera letra de nuestro nombre de usuario localizado en la esquina inferior izquierda) y de ahí a «Módulos de autenticación multifactor» > Añadir y seguimos las instrucciones.

Si necesitamos ayuda para verificar la conectividad con nuestro sistema por el puerto que hemos expuesto, podemos usar una herramienta cómo OpenPortCheckTool especificando el puerto 8123 (por ejemplo). Si lo que queremos es saber la IP privada de nuestro sistema una herramienta muy útil es WirelessNetworkWatcher.

Por último, una opción muy interesante es limitar el nº posible de intentos de acceso por IP; esto es, establecer un baneo automático por IP para aquellas direcciones que intentasen acceder insatisfactoriamente a nuestro equipo más de un nº de veces. Para ello, sólo hay que añadir un par de líneas a la opción «http» del fichero configuration.yaml que editamos antes:

# Remote access
http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem
  
  # Esto baneará cualquier IP que falle 10 intentos de acceso erróneos
  ip_ban_enabled: true
  login_attempts_threshold: 10

🍺 Buy me a beer!