SCOPI DELLA GUIDA:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTIlIZZATE:
PREREQUISITI:
DISPOSITIVI FISICI UTILIZZATI:
|
Guida indicata per utenti con installazione: |
|
NOTE E DISCLAIMER
|
|
| Revisione guida: 1.4 | |
😊 QUESTA GUIDA È PARTE DEL NOSTRO PERCORSO GUIDATO ALL’INSTALLAZIONE E CONFIGURAZIONE di HOME ASSISTANT.
Abstract
| ATTENZIONE: QUESTA GUIDA È ADATTA A TUTTE LE TIPOLOGIE DI INSTALLAZIONE HOME ASSISTANT E TUTTE LE TIPOLOGIE DI CONNESSIONE INTERNET. Semplicemente, è una strada (quasi) obbligata per chi non ha acesso diretto a Internet perché il proprio provider fornisce connessione sotto NAT, come spieghiamo in subito dettaglio a seguire. |
Come spiegato anche durante un episodio del nostro podcast, la sicurezza in ambito domotico non è mai troppa. Non la è mai in assoluto, ma quando si corre il rischio di esporre a eventuali malintenzionati le nostre componenti domotiche (poco male quando si tratta di illuminazione, va peggio quando si parla di allarmi, di serrature o altro) è necessario dotarsi di un sistema il più possibile sicuro.
Per coloro che abbiano saggiamente deciso di adottare l’HUB personale Home Assistant, uno degli scogli più importanti da affrontare è quello di renderlo raggiungibile dall’esterno del propio ambiente domotico, possibilmente in modo sicuro.
Home Assistant offre di suo la possibilità di inibire l’accesso tramite una gestione vera e propria di utenze che abbiano diritto all’accesso. Quel che rimane scoperto (di base) è l’uso della crittografia per la trasmissione dei dati, la quale se implementata ci tutela a fronte di eventuali reti non sicure nelle quali qualcuno “in ascolto” potrebbe intercettare i dati in transito, credenziali di accesso incluse.
Ciò però che fa da spartiacque è la tipologia di connessione Internet del server che ospita Home Assistant.
Per lo più le connessioni domestiche o lavorative a Internet sono fornite dai provider d’accesso attraverso – genericamente parlando – di modem/router, i quali offrono intrinsecamente un servizio NAT (Network Address Translator), personalizzabile, il quale funge da “ponte” tra la rete locale, gestita – genericamente – dalla componente router e la rete Internet (WAN), gestita dalla componente – genericamente – modem.
Il funzionamento è abbastanza semplice da comprendere: mentre gli host presenti sulla rete locale sono per lo più in comunicazione diretta, per far sì che essi parlino con gli host presenti su Internet è necessario che le loro richieste vengano instradate dal servizio NAT presente sul modem/router (genericamente parlando, non lo ripetiamo più) verso Internet e, a fronte di risposte, esse vengano instradate verso la rete locale nonché verso l’host specifico che ha generato la richiesta. Esempio: dal nostro portatile apriamo tramite browser il sito https://indomus.it: prima viene automaticamente risolto il record DNS relativo a tale nome, che corrisponde a un indirizzo IP Internet, poi la richiesta viene instradata dal NAT verso Internet e, quando i primi pacchetti dati di risposta arrivano dal sito web, il NAT li rigira al nostro portatile che, tramite browser, ricostruisce la pagina e la visualizza a schermo.
Ma che succede se e quando è un host Internet (per esempio il nostro smartphone) a chiedere di comunicare con uno (o più) presente/i sulla nostra rete privata (per esempio quello che ospita Home Assistant)?
Dato che il modem/router (l’abbiamo già detto che stiamo parlando genericamente?) solitamente presenta un indirizzo IP WAN Internet (fisso o variabile, non è importante) e gli host dietro di lui, sulla rete locale, sono privati e sono più d’uno, solitamente si utilizza il port forwarding, ovvero si configura il modem/router in modo che, a fronte di richieste dall’esterno su specifiche porte, esse vengano girate a un’host specifico della rete locale. Esempio: è quel che succede laddove si voglia “esporre” Home Assistant alla rete Internet. Il modo più banale, infatti, è configurare una regola di port forwarding che “giri” tutte le chiamate in arrivo verso l’IP WAN Internet del modem/router sulla porta 8123 (la porta standard di Home Assistant, oppure altre fuori standard) verso uno specifico host presente sulla rete locale (che ovviamente ospiti Home Assistant).
Questo funziona quando il provider di accesso Internet fa sì che al nostro modem/router venga effettivamente assegnato un indirizzo IP WAN Internet contattabile da remoto.
| N.b. In questi casi (ovvero la maggioranza), è possibile collegarsi a Home Assistant semplicemente e gratuitamente utilizzando la classica modalità via Reverse Proxy, o altro. Comunque sia, la presente guida è adatta anche per chi volesse collegarsi in modo sicuro utilizzando un proprio dominio (a pagamento) sfruttando i meccanismi di messa in sicurezza gratuiti di Cloudflare, che per esempio evitano di dover “aprire” porte sul proprio router/modem. |
Ma cosa accade quando il provider non lo fa? Capita, per esempio, per alcuni provider Italiani, per lo più con connessioni via rete mobile o di alcuni specifici provider sulle connessioni fisse, come in alcuni casi Fastweb, Sky Wi-Fi o altri. Questo perché, dopo il nostro modem/router, il provider colloca un ulteriore servizio NAT, creando un’ulteriore rete privata intermedia. I motivi sono i più disparati, tecnici e commerciali, ma questo fa sì che, non essendo un servizio NAT sul quale l’utente abbia modo di agire, la cosa causa l’impossibilità di raggiungere, da Internet, il proprio modem/router – e quindi, volendo, la propria rete locale sui quali eventualmente alberghino servizi di varia natura (come per esempio il sopracitato Home Assistant).
Questo, ovviamente, rappresenta un problema.
Ipotizziamo infatti di possedere un modem/router che, per collegarsi alla rete Internet, utilizzi una SIM dati (eg. FRITZ!Box o altri modem che si colleghino tramite rete mobile), oppure un provider “sotto NAT”: salvo casistiche particolari (specialmente dal punto di vista commerciale), tale connessione non disporrà di un IP WAN Internet, ma di un IP relativo alla rete privata del fornitore d’accesso – introducendo i problemi di cui sopra.
Come soluzione, c’è la possibilità di utilizzare il servizio Cloudflare che, gratuitamente, consente di realizzare un tunnel allo scopo di aggirare la limitazione del NAT. Questa è la tecnica spiegata nella presente guida.
| N.b. Come già spiegato in testa, questa guida non è necessariamente dedicata solo a chi possieda una connessione “sotto NAT”: chiunque, infatti, indipendentemente dalla tipologia della propria connessione, può sfruttarla per realizzare il collegamento sicuro da remoto verso Home Assistant utilizzando un proprio dominio personale e beneficiando di vari aspetti “laterali” legati alla sicurezza introdotta dall’uso di Cloudflare. Unico problema, la sua adozione prevede un piccolo esborso economico; l’alternativa gratuita, per chi fosse “sotto NAT”, è quest’altra guida.
Se si vuole capire quale sia la propria condizione (connessione diretta oppure “sotto NAT”, consigliamo la lettura di questo FOCUS). |
Si parte
Assunti
L’intera guida si basa sull’assunto che la propria istanza di Home Assistant sia già operativa e risponda al classico indirizzo di base
http://INDIRIZZO_IP_LOCALE_DI_HOME_ASSISTANT:8123
senza, quindi, alcuna configurazione specifica legata a certificati crittografici SSL né altro: un’installazione “base”. Tale istanza può essere installata virtualmente ovunque e può trattarsi di un’istanza Core come Home Assistant OS o Supervised: è indifferente.
Approccio
Quel che serve è un servizio Internet che funga da “ponte” per le chiamate che desideriamo canalizzare da Internet verso la nostra rete. Per far ciò utilizzeremo protocolli di tunnelling offerti da Cloudflare.
Tali servizi consentono a un host (in questo caso della nostra rete privata) di collegarsi a una rete remota “come si fosse fisicamente connessi ad essa” – ottenendo un indirizzo IP privato di quella rete – è qualcosa di utile e realizzabile facilmente e in buona sicurezza.
Da una parte avremo quindi il nostro placido host domestico che fornisce il servizio Home Assistant; dall’altra, invece, configureremo un servizio Internet gratuito, “Cloudflare“, il quale “giri” automaticamente tutte le chiamate ricevute per il nostro dominio verso la nostra istanza Home Assistant interno alla nostra rete privata; che funga, in pratica, da Reverse Proxy, gestendo al contempo anche i certificati per la comunicazione sicura, il tutto sfruttando un tunnel sicuro.
| N.b. Anche per quanto riguarda la gestione dinamica dell’associazione indirizzo IP WAN / dominio, non sarà necessario effettuare particolari configurazioni: provvederà a tutto il servizio proposto dalla presente guida, ovvero Cloudflare. |
Dominio personale
Affinché sia raggiungibile dall’esterno in modo semplificato, la nostra istanza Home Assistant verrà rappresentata da un nome dominio (chiamato FQDN), ipotizziamo:
casamia.com
ma potrebbe essere anche “mariorossi.org”, “miodominio.com” eccetera.
GoDaddy è il servizio che abbiamo scelto per questa funzione di fornitura di FQDN, ma l’utente è libero di utilizzare il registrant che meglio creda: l’importante è che sia possibile gestire, in autonomia, la propria zona DNS.
Cloudflare
Per procedere con la presente guida è necessario, arrivati a questo punto e capito a grandi linee quanto spiegato, fare sì che la propria zona DNS relativa al proprio FQDN sia gestita da Cloudflare, ovvero fare in modo che sia Cloudflare a gestirne i record, i reindirizzamenti, il tunnelling che andremo a definire e, volendo, altro.
Per farlo è necessario attuare in toto la seguente, breve guida:
Configurare Cloudflare per il proprio dominio personale (per protezione, reverse proxy, CDN e altro)
Al termine dell’attuazione della guida sopra, qualsiasi risoluzione verso il dominio personale scelto “passerà” attraverso i nameserver di Cloudflare e, nello specifico degli scopi della guida, il traffico del tunnel che ci serve verrà indirizzato in modo appropriato verso la nostra rete privata.
Home Assistant
Configurato il nostro dominio su Cloudflare siamo dunque pronti a configurare il nostro HUB in modo da accettare il traffico che ClouFlare canalizzerà verso di lui.
Le azioni da effettuare sono diverse in funzione delle varie, possibili installazioni; noi illustreremo le procedure per:
- Home Assistant OS / Home Assistant Supervised
- Home Assistant Core su Docker (su Debian, Raspberry Pi OS o genericamente Linux)
- Home Assistant Core installato come applicativo sotto venv (su Debian, Raspberry Pi OS o genericamente Linux)
Altre, eventuali installazioni potranno comunque prendere spunto dalle proposizioni di cui sopra in elenco.
Home Assistant OS / Supervised
Come prima cosa è necessario effettuare una modifica al proprio file di configurazione (magari usando File editor), andando a impostare la chiave http: come segue:
http: use_x_forwarded_for: true trusted_proxies: - 172.30.33.0/24
Al termine della modifica, riavviare Home Assistant.
A questo punto è possibile provvedere all’installazione dei processi utili a Cloudflare, i quali vengono eseguiti come add-on Home Assistant OS/Supervised. Si tratta, però, di un elemento custom, pertanto non nativamente disponibile presso l’add-on store di Home Assistant OS.
Per installare l’add-on, cliccare, presso il menu, la voce “Impostazioni” > “Componenti aggiuntivi” e poi sul pulsante “Raccolta di componenti aggiuntivi“.
Si tratta di accedere ad una vera e propria “vetrina” di componenti aggiuntivi (gratuiti) che, proprio come mattoncini da costruzioni, andranno ad arricchire le funzionalità del nostro HUB. Per installarlo è primariamente necessario aggiungere un repository alla lista di quelli già presenti, nello specifico questo indirizzo:
https://github.com/brenner-tobias/ha-addons
Per farlo, recarsi alla voce di menu “Repository” > “Aggiungi“.
Successivamente, cercare tra gli add-on disponibili “Cloudflare”: si troverà “Cloudflared“:
Cliccarci sopra per accedere alla scheda di dettaglio, poi cliccare su “INSTALLA“:
Al termine dell’installazione, non avviare il l’add-on: è necessario, prima, configurarlo.
A questo punto è necessario recarsi, presso la scheda dell’add-on Cloudflared, alla voce “Configurazione“. Alla voce “External Home Assistant Hostname” inserire il proprio dominio:
Salvare, dopodiché tornare alla scheda principale, verificare di aver selezionato “Esegui all’avvio” e “Watchdog“, infine cliccare su “AVVIA“.
Portarsi su “Registro” e cliccare su “AGGIORNA“. Verrà mostrato un log di questo tipo:
il quale indica chiaramente l’indirizzo (riquadro rosso) al quale recarsi, tramite browser, per autorizzare il tunnel che l’add-on sta tentando di stabilire con Cloudflare.
Copia-incollare dunque l’indirizzo e aprirlo tramite browser; una volta autenticati su Cloudflare, autorizzare il tunnel:
Torniamo dunque su Home Assistant e alla scheda relativa all’add-on Cloudflared, nello specifcio sulla voce “Registro“: clicchiamo su “AGGIORNA” e, se tutto sarà andato bene, apparirà un log come il seguente che indicherà che la procedura è stata completata con successo:
A partire da ora la propria istanza Home Assistant risponderà all’indirizzo scelto, per esempio:
https://casamia.com
dove ovviamente casamia.com è un dominio d’esempio, che andrà personalizzato in base al proprio dominio (eg. https://miodominio.com eccetera).
| N.b. La “s” rossa nell’indirizzo indica la presenza, garantita implicitamente, di una connessione sicura garantita da Cloudflare tramite l’emissione e l’applicazione automatiche di certificati di sicurezza SSL. |
A questo punto si può saltare alle conclusioni.
Home Assistant Core su Docker
| N.b. Si assume che Core sia installato su Docker presso un sistema operativo Debian o Raspberry Pi OS. La procedura qui descritta portrebbe essere a grandi linee la medesima, comunque, anche su altri sistemi operativi Linux-based. |
Arrivati a questo punto è possibile provvedere all’installazione Cloudflared, una mini applicazione per la gestione automatica del tunnel la quale viene eseguita come container Docker tramite un’istanza specifica.
In ambito Docker, l’istanziamento dell’applicazione può essere effettuato tramite esecuzione di un comando manuale (più immediato) oppure tramite una configurazione del tool di gestione Docker Compose, approccio inizialmente più ostico ma che consigliamo per tutta una serie di motivi. Entrambe le scelte sono valide, ma in prospettiva (specie in ottica di aggiornamento) imparare ad usare Docker Compose è altamente consigliato.
Prima di procedere, però, è necessario creare una cartella la quale conterrà la sua configurazione ed eventuali file statici.
Una volta collegati via SSH al computer ospitante tramite una propria utenza (eg. “deb“), provvedere a creare la cartella:
mkdir /home/deb/cloudflared
chmod 777 cloudflared
avendo cura di adeguare il comando in funzione dell’utenza in uso (nell’esempio, appunto, “deb“).
Provvediamo ora all’istanziamento vero e proprio dell’applicazione, utilizzando come spiegato prima o il comando “docker run” o la più versatile configurazione Docker Compose.
Tramite comando “docker run”
Istanziamo dunque Cloudflared su Docker tramite il comando:
docker run -it --rm --name cloudflared -v /home/deb/cloudflared:/home/nonroot/.cloudflared cloudflare/cloudflared:latest tunnel login
avendo anche qui cura di adeguare il comando in funzione dell’utenza in uso (nell’esempio, appunto, “deb“).
Eseguendo il comando, apparirà:
Please open the following URL and log in with your Cloudflare account:
https://dash.cloudflare.com/argotunnel?callback=https%3A%2F%2Flogin.cloudflareaccess.org%2Fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Leave cloudflared running to download the cert automatically.
1980-01-01T00:00:00Z INF Waiting for login...
La riga in rosso indica chiaramente l’indirizzo (riquadro rosso) al quale recarsi, tramite browser, per autorizzare il tunnel che l’add-on sta tentando di stabilire con Cloudflare.
Copia-incollare dunque l’indirizzo e aprirlo tramite browser; una volta autenticati su Cloudflare, autorizzare il tunnel:
Dopo qualche secondo dalla shell dalla quale abbiamo avviato il container verrà mostrato un messaggio analogo a questo:
You have successfully logged in.
If you wish to copy your credentials to a server, they have been saved to:
/home/nonroot/.cloudflared/cert.pem
Presso la directory cloudflared/ sarà presente il nuovo file cert.pem; a questo punto è necessario “battezzare” il tunnel con un nome indicativo a proprio piacimento, eseguendo il comando:
docker run -it --rm -v /home/utente/cloudflared:/home/nonroot/.cloudflared cloudflare/cloudflared:latest tunnel create TUNNELNAME
avendo cura di adeguare il comando in funzione del nome da usare, sostituendo la parola “TUNNELNAME” (in fondo al comando).
La risposta al comando sarà qualcosa tipo:
Tunnel credentials written to /home/nonroot/.cloudflared/UUID.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel TUNNELNAME with id xxxxx
Nella stessa directory di prima sarà presente un nuovo file .json, il cui nome sarà quello della stringa UUID ricevuta sopra, indicata in rosso (eg. c0ea6c80-b2a1-41d2-1268-f54aaa226e4d). L’importante è appunto tale nome: occorrerà per i prossimi step.
Sempre nella stessa directory creiamo un file config.yml:
nano /home/deb/cloudflared/config.yml
avendo anche qui cura di adeguare il comando in funzione dell’utenza in uso (nell’esempio, appunto, “deb“).
Copia-incollare il seguente codice:
tunnel: UUID
credentials-file: /home/nonroot/.cloudflared/UUID.json
url: http://ip_lan:8123
avendo cura di adeguare il codice sostituendo UUID con la stringa UUID di cui sopra e indicando, al posto di ip_lan:8123 l’indirizzo locale di Home Assistant.
Uscire salvando (CTRL+X, Y, invio).
Ora è necessario creare una regola di routing sul container Docker dell’app Cloudflared creato poco fa. Lanciare il seguente comando sostituendo UUID con il propria stringa UUID, miodominio.com con il proprio dominio e infine l’utente deb con il proprio utente:
docker run -it --rm -v /home/deb/cloudflared:/home/nonroot/.cloudflared cloudflare/cloudflared:latest tunnel route dns UUID miodominio.com
verrà mostrato un log come segue, a indicare l’esito positivo:
1980-01-01T00:00:00Z INF Added CNAME miodominio.com which will route to this tunnel tunnelID=UUID
La configurazione è completa. Ora non manca che avviare realmente il servizio e quindi il tunnel:
docker run -d --name="cloudflared" -v "/home/deb/cloudflared:/home/nonroot/.cloudflared" --restart always cloudflare/cloudflared:latest
avendo anche qui cura di adeguare il comando in funzione dell’utenza in uso (nell’esempio, appunto, “deb“).
Bene, ora è il momento di riconfigurare Home Assistant, come da paragrafo più avanti (quello che segue immeditamente è invece relativo alla configurazione di quanto appena configurato, ma via docker compose).
Tramite Docker Compose
Se astutamente si sceglie di utilizzare Docker Compose, allora è semplicemente necessario aggiungere al proprio file docker-compose.yaml la seguente configurazione (sotto il bocco services):
cloudflared:
container_name: cloudflared
hostname: cloudflared
image: cloudflare/cloudflared:latest
restart: always
volumes:
- /home/deb/cloudflared:/home/nonroot/.cloudflared
command: tunnel run UUID
avendo cura di adeguare il codice sostituendo UUID con la stringa UUID di cui sopra e il path in funzione dell’utenza in uso (nell’esempio, appunto, “deb“).
Una volta salvato il file docker-compose.yaml, eseguire il comando:
docker-compose run --rm cloudflared tunnel login
Eseguendo il comando, apparirà:
Please open the following URL and log in with your Cloudflare account:
https://dash.cloudflare.com/argotunnel?callback=https%3A%2F%2Flogin.cloudflareaccess.org%2Fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Leave cloudflared running to download the cert automatically.
1980-01-01T00:00:00Z INF Waiting for login...
La riga in rosso indica chiaramente l’indirizzo (riquadro rosso) al quale recarsi, tramite browser, per autorizzare il tunnel che l’add-on sta tentando di stabilire con Cloudflare.
Copia-incollare dunque l’indirizzo e aprirlo tramite browser; una volta autenticati su Cloudflare, autorizzare il tunnel:
Dopo qualche secondo sulla shell dalla quale abbiamo avviato il container verrà mostrato un messaggio analogo a questo:
You have successfully logged in.
If you wish to copy your credentials to a server, they have been saved to:
/home/nonroot/.cloudflared/cert.pem
Presso la directory cloudflared/ sarà presente il nuovo file cert.pem; a questo punto è necessario “battezzare” il tunnel con un nome indicativo a proprio piacimento, eseguendo il comando:
docker-compose run --rm cloudflared tunnel create TUNNELNAME
avendo cura di adeguare il comando in funzione del nome da usare, sostituendo la parola “TUNNELNAME” (in fondo al comando).
La risposta al comando sarà qualcosa tipo:
Tunnel credentials written to /home/nonroot/.cloudflared/UUID.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel TUNNELNAME with id xxxxx
Nella stessa directory di prima sarà presente un nuovo file .json, il cui nome sarà quello della stringa UUID ricevuta sopra, indicata in rosso (eg. c0ea6c80-b2a1-41d2-1268-f54aaa226e4d). L’importante è appunto tale nome: occorrerà per i prossimi step.
Sempre nella stessa directory creiamo un file config.yml:
nano /home/deb/cloudflared/config.yml
Copia-incollare il seguente codice:
tunnel: UUID
credentials-file: /home/nonroot/.cloudflared/UUID.json
url: http://ip_lan:8123
avendo cura di adeguare il codice sostituendo UUID con la stringa UUID di cui sopra e indicando, al posto di ip_lan:8123 l’indirizzo locale di Home Assistant.
Uscire salvando (CTRL+X, Y, invio).
Ora è necessario creare una regola di routing sul container Docker dell’app Cloudflared creato poco fa. Lanciare il seguente comando sostituendo UUID con il propria stringa UUID, miodominio.com con il proprio dominio:
docker-compose run --rm cloudflared tunnel route dns UUID miodominio.com
verrà mostrato un log come segue, a indicare l’esito positivo:
1980-01-01T00:00:00Z INF Added CNAME miodominio.com which will route to this tunnel tunnelID=UUID
La configurazione è completa. Ora non manca che avviare realmente il servizio e quindi il tunnel modificando la configurazione del proprio file docker-compose.yaml adeguandolo come segue:
cloudflared:
container_name: cloudflared
hostname: cloudflared
image: cloudflare/cloudflared:latest
restart: always
volumes:
- /home/deb/cloudflared:/home/nonroot/.cloudflared
command: tunnel run UUID
avendo cura di adeguare il codice in funzione dell’utenza in uso (nell’esempio, appunto, “deb“).
Una volta salvato il file docker-compose.yaml, eseguire il comando:
docker-compose up -d cloudflared
Ora è il momento di riconfigurare Home Assistant, come da paragrafo che segue.
Riconfigurare Home Assistant
A questo punto è necessario indicare a Home Assistant che tutto il traffico esterno gli arriverà attraverso Cloudflared.
Per farlo è sufficiente effettuare una piccola modifica presso il file di configurazione dell’HUB, modificandolo con l’aggiunta (o modifica) del blocco “http:“, come segue.
http:
use_x_forwarded_for: true
trusted_proxies:
- XXX.XXX.XXX.XXX
dove “XXX.XXX.XXX.XXX” rappresenterà l’indirizzo IP del reverse proxy (o la classe IP), il quale può essere:
- 127.0.0.1, se Caddy o il reverse proxy è installato sulla stesso computer di Home Assistant come servizio;
- 172.0.0.0/8 (solitamente*), se l’app Cloudflared è installato su Docker sulla stesso computer di Home Assistant (anch’esso installato su Docker);
- l’indirizzo IP LAN di Cloudflared, se installato su un computer diverso da quello di Home Assistant.
È possibile aiutarsi col comando:
docker network inspect bridge | grep Subnet
| * la classe indicata potrebbe essere un’altra. Verificare sui log l’eventuale presenza dell’errore Received X-Forwarded-For header from an untrusted proxy: l’IP indicato nell’errore indica implicitamente la classe IP da indicare in configurazione per risolvere il problema. |
Completata la modifica, salvare e riavviare Home Assistant. Una volta riportato, Home Assistant dovrebbe essere correttamente controllabile da remoto (e in locale) in modo sicuro tramite l’indirizzo appena configurato:
dove ovviamente casamia.com è un dominio d’esempio, che andrà personalizzato in base al proprio dominio (eg. https://miodominio.com eccetera).
| N.b. La “s” rossa nell’indirizzo indica la presenza, garantita implicitamente, di una connessione sicura garantita da Cloudflare tramite l’emissione e l’applicazione automatiche di certificati di sicurezza SSL. |
Arrivati a questo punto si può saltare alle conclusioni.
Home Assistant Core (sotto venv)
| N.b. Si assume che Core sia installato sotto venv presso un sistema operativo Debian o Raspberry Pi OS. La procedura qui descritta portrebbe essere a grandi linee la medesima, comunque, anche su altri sistemi operativi Linux-based. |
Come prima cosa è necessario effettuare una modifica al proprio file di configurazione, andando a impostare la chiave http: come segue:
http: use_x_forwarded_for: true trusted_proxies: - 127.0.0.1 - ::1
Al termine della modifica, riavviare Home Assistant.
Arrivati a questo punto è possibile provvedere all’installazione Cloudflared, una mini applicazione per la gestione automatica del tunnel.
Una volta collegati via SSH al computer ospitante tramite una propria utenza (eg. “deb“), scaricare il pacchetto dell’applicazione:
wget -q https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb && dpkg -i cloudflared-linux-amd64.deb
Eseguire poi il seguente comando:
cloudflared tunnel login
Eseguendo il comando, apparirà:
Please open the following URL and log in with your Cloudflare account:
https://dash.cloudflare.com/argotunnel?callback=https%3A%2F%2Flogin.cloudflareaccess.org%2Fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Leave cloudflared running to download the cert automatically.
1980-01-01T00:00:00Z INF Waiting for login...
La riga in rosso indica chiaramente l’indirizzo (riquadro rosso) al quale recarsi, tramite browser, per autorizzare il tunnel che l’add-on sta tentando di stabilire con Cloudflare.
Copia-incollare dunque l’indirizzo e aprirlo tramite browser; una volta autenticati su Cloudflare, autorizzare il tunnel:
Dopo qualche secondo sulla shell dalla quale abbiamo avviato il container verrà mostrato un messaggio analogo a questo:
You have successfully logged in.
If you wish to copy your credentials to a server, they have been saved to:
/home/nonroot/.cloudflared/cert.pem
Presso la directory .cloudflared/ sarà presente il nuovo file cert.pem; a questo punto è necessario “battezzare” il tunnel con un nome indicativo a proprio piacimento, eseguendo il comando:
cloudflared tunnel create TUNNELNAME
avendo cura di adeguare il comando in funzione del nome da usare, sostituendo la parola “TUNNELNAME” (in fondo al comando).
La risposta al comando sarà qualcosa tipo:
Tunnel credentials written to /home/deb/.cloudflared/UUID.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel TUNNELNAME with id xxxxx
Nella stessa directory di prima sarà presente un nuovo file .json, il cui nome sarà quello della stringa UUID ricevuta sopra, indicata in rosso (eg. c0ea6c80-b2a1-41d2-1268-f54aaa226e4d). L’importante è appunto tale nome: occorrerà per i prossimi step.
Sempre nella stessa directory creiamo un file config.yml:
nano /home/deb/cloudflared/config.yml
Copia-incollare il seguente codice:
tunnel: UUID
credentials-file: /home/nonroot/.cloudflared/UUID.json
url: http://ip_lan:8123
avendo cura di adeguare il codice sostituendo UUID con la stringa UUID di cui sopra e indicando, al posto di ip_lan:8123 l’indirizzo locale di Home Assistant.
Uscire salvando (CTRL+X, Y, invio).
Ora è necessario creare una regola di routing su Cloudflared. Lanciare il seguente comando sostituendo UUID con il propria stringa UUID, miodominio.com con il proprio dominio:
cloudflared tunnel route dns UUID miodominio.com
verrà mostrato un log come segue, a indicare l’esito positivo:
1980-01-01T00:00:00Z INF Added CNAME miodominio.com which will route to this tunnel tunnelID=UUID
La configurazione è completa. Ora non manca che avviare realmente il servizio e quindi il tunnel:
cloudflared tunnel run
A partire da ora la propria istanza Home Assistant risponderà all’indirizzo scelto, per esempio:
https://casamia.com
dove ovviamente casamia.com è un dominio d’esempio, che andrà personalizzato in base al proprio dominio (eg. https://miodominio.com eccetera).
| N.b. La “s” rossa nell’indirizzo indica la presenza, garantita implicitamente, di una connessione sicura garantita da Cloudflare tramite l’emissione e l’applicazione automatiche di certificati di sicurezza SSL. |
Conclusioni
Arrivati sin qui, abbiamo ottenuto molteplici risultati:
- Home Assistant è contattabile da remoto e in modo sicuro;
- non abbiamo dovuto “aprire porte” sul router;
- la gestione del rinnovo dei certificati di sicurezza è completamente automatica;
- per alcuni versi, l’istanza è protetta dai sistema gratuiti offerti da Cloudflare (volendo tali funzionalità sono espandibili, ma a pagamento).
Buona domotica!
|
⚠️ Se di Home Assistant ne sai poco ma sei interessato a capirne di più, ti suggeriamo di partire da qui. |
| Questa pagina è redatta, manutenuta e aggiornata dallo staff di inDomus, un gruppo di persone molto diverse tra loro che trovi, per domande e supporto, sul forum e sulla chat del sito. Se ti sei perso, a tua disposizione c'è la mappa. |