SCOPI DELLA GUIDA:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTIlIZZATE:
PREREQUISITI:
DISPOSITIVI FISICI UTILIZZATI:
|
Guida indicata per utenti con installazione: |
|
NOTE E DISCLAIMER
|
|
| Revisione guida: 1.1 | |
😊 QUESTA GUIDA È PARTE DEL NOSTRO PERCORSO GUIDATO ALL’INSTALLAZIONE E CONFIGURAZIONE di HOME ASSISTANT.
Abstract
ATTENZIONE: MALGRADO QUESTA GUIDA DIDATTICA SIA EFFETTIVAMENTE FUNZIONANTE, È PER ALCUNI PARTICOLARMENTE COMPLESSA DA ATTUARE E DA CAPIRE; INOLTRE, NON SI TRATTA DELLE SOLUZIONE MIGLIORE POSSIBILE. IN GENERALE, CONSIGLIAMO PIUTTOSTO DI ADOTTARE QUEST’ALTRA GUIDA, BASATA SU CLOUDFLARE, CON GLI STESSI SCOPI MA MOLTO PIÙ EFFICACE, SEMPLICE E VALIDA. DI BUONO, QUESTA HA CERTAMENTE IL FATTO DI ESSERE COMPLETAMENTE GRATUITA.
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) 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.
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.
Ma la soluzione gratuita c’è – ed ecco il senso della presente guida. Diversamente, a pagamento rimane sempre disponibile (almeno per Home Assistant) il servizio Nabu Casa.
Chi invece, più fortunatamente, non ha problemi di questo tipo, per configurare al meglio la connessione remota di Home Assistant deve piuttosto quest’altra guida.
Si parte
- Assunti
- Approccio
- Dominio
- Server remoto
- Google Cloud Platform
- Aggiornamento dominio (FQDN)
- Installare e configurare la VPN
- Firewall
- Routing
- Google Cloud Platform
- Host locale
Assunti
L’intera guida si basa sull’assunto che la propria istanza di Home Assistant sia 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é gestione DDNS: un’installazione “base”. Tale istanza può essere installata virtualmente ovunque e può trattarsi di un’istanza Core come Home Assistant OS: è indifferente.
Approccio
Dato che ovviamente anche in presenza di una connessione “dietro NAT” le connessioni effettuate “in uscita” dagli host della rete locale ottengono effettivamente delle risposte da Internet (altrimenti non si navigherebbe) e a non funzionare sono semmai le chiamate “dall’esterno all’interno“, sfrutteremo dunque la prima caratteristica per aggirare il problema.
Quel che serve è un host presente su Internet che funga da ponte per le chiamate che desideriamo canalizzare da Internet verso la nostra rete. Ma non abbiamo detto che le chiamate da Internet verso l’interno non possono transitare, ma semmai solo quelle da dentro verso Internet?
Sì, ed è per questo che utilizzeremo i protocolli di tunnelling per risolvere il problema.
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, il quale risponde a
http://INDIRIZZO_IP_LOCALE_DI_HOME_ASSISTANT:8123.
dall’altra, invece, configureremo un host Internet, un server remoto il quale:
- gestisca l’associazione dinamica del proprio IP WAN Internet con un nome DDNS (per esempio casamia.duckdns.org);
- fornisca un accesso VPN;
- “giri” automaticamente tutte le chiamate ricevute su se stesso all’indirizzo casamia.duckdns.org e sulla porta 8123 (la porta di default di Home Assistant) verso il nostro host locale, nel frattempo collegatosi tramite VPN al server remoto.
Routing
Il sopracitato terzo punto è cruciale. Esistono infatti due modalità affinché il server remoto “giri” le richieste al nostro host locale:
- tramite semplici regole di routing statiche configurate ad hoc sul server remoto (tutto il traffico esterno per una data porta viene girato così com’è verso l’host locale);
- tramite Reverse Proxy, servizio che viene installato sul server remoto e che, sulla base di regole, non solo effettui il routing, ma provvede anche a ottenere e gestire certificati crittografici di sicurezza.
In realtà anche nel primo caso (regole di routing statiche) nessuno ci vieta di installare un Reverse Proxy sull’host locale, in modo che ricevendo le comunicazioni da parte del server remoto, provveda poi lui a gestire le comunicazioni sicure tramite certificati di sicurezza.
In questa guida illustreremo tutte queste casistiche.
Dominio
| N.b. Se si possiede un dominio proprio o comunque una gestione DDNS diversa da DuckDNS, si può saltare direttamente alla sezione successiva. |
Affinché sia raggiungibile dall’esterno in modo semplificato, il server remoto dovrà esser rappresentato da un nome univoco (chiamato FQDN) il quale veda l’IP WAN Internet ad esso associato aggiornarsi automaticamente ad ogni eventuale variazione. Per fare questo interviene il servizio Dynamic DNS (o DDNS), ovvero un servizio che tenga traccia dell’ultima variazione e risponda, ai sistemi che chiedano la risoluzione (traduzione) del nome DNS, l’ultimo IP conosciuto, ovvero quello in uso.
DuckDNS è il servizio che abbiamo scelto per questa funzione di fornitura di FQDN nonché di associazione dinamica dell’IP.
Collegarsi quindi al servizio tramite l’indirizzo https://www.duckdns.org e, una volta registrati creare un proprio nome dominio che, univocamente, rappresenterà il vostro modem collegato ad Internet. Il suffisso è sempre lo stesso (“.duckdns.org“) mentre ciò che cambia e va scelto è il suffisso (per esempio “casamia“).
Per questa guida, daremo per assunto di aver creato il seguente FQDN:
casamia.duckdns.org
dove “duckdns.org” è la parte fissa mentre casamia è il nome di dominio da noi creato a mo’ di esempio.
All’interno della vostra sezione privata di DuckDNS troverete anche un campo importante chiamato “token“, il quale appare analogo a questo:
e3ff465f-c6d6-acb1-4416-44b2af152111
Appuntarselo da una parte, tornerà utile più avanti.
Server remoto
Le caratteristiche che deve avere un server remoto utile agli scopi della presente guida sono:
- l’esposizione su Internet (deve possedere un IP WAN Internet);
- deve essere configurabile in modo da installarvi per lo meno un server VPN;
- deve essere configurabile in modo da configurare regole di routing per girare il traffico in base alle proprie esigenze.
I server di questo tipo possono essere il prodotto di migliaia di diverse casistiche tecnico/commerciali, quindi non è possibile trattarle tutte: è davvero possibile utilizzare qualsiasi soluzione personale.
A mo’ di traccia, su questa guida ci concentreremo su un esempio specifico, ovvero l’implementazione di una VM, ovvero un server gratuito* presso Google Cloud Platform (GCP).
| * L’esempio che riporteremo ha sì lo scopo di dotarsi di un server (VM) su Google Cloud Platform a costo zero, ma sarà sempre e comunque compito e responsabilità dell’utente (come da contratto con Google) monitorare e verificare che la propria configurazione sia effettivamente sempre gratuita in modo da non dare luogo a fatturazioni da parte del provider. |
Google Cloud Platform
Bene, siamo pronti quindi per realizzare il nostro server privato, che nel caso della presente guida sarà una VM istanziata presso Google Cloud Platform.
A tale scopo seguire la presente guida:
Istanziare una VM Linux Debian su Google Cloud Platform (GCP) per uso personale
la quale fornirà all’utente un server virtuale basato su Linux Debian. Laddove si voglia usare altro, l’utente è libero di implementare ciò che meglio ritiene opportuno.
Aggiornamento dominio (FQND)
Terminata la configurazione del server, procedere alla configurazione dei processi automatici di associazione dell’IP WAN Internet del server virtuale con il proprio nome dominio (FQDN).
Per questa guida noi suggeriamo l’adozione sul server remoto di DuckDNS, come da guida che segue:
Aggiornare il proprio record su DuckDNS tramite Linux Debian
Anche in questo caso l’utente è libero di utilizzare ciò che meglio ritiene opportuno – l’importante però è che si faccia in modo che l’associazione FQDN – IP WAN Internet del server sia sempre garantita come aggiornata.
Installare e configurare la VPN
Arrivati a questo punto abbiamo a disposizione:
- un server privato Linux Debian esposto su Internet;
- un nome dominio (eg. casamia.duckdns.org) che, se risolto, “punta” all’indirizzo IP WAN Internet di tale server.
È dunque il momento di dotare tale server di un servizio VPN Server che consenta all’host privato, successivamente, di collegarvisi e creare un “tunnel” tra i due.
Noi suggeriamo l’adozione di OpenVPN (poi, come sempre, l’utente è libero di fare come meglio crede) come da guida che segue per il server remoto GCP sin qui configurato:
Terminata l’installazione e la configurazione della VPN basata su OpenVPN, avremo:
- il nome dell’host VPN (che ovviamente coincide con il nostro FQND, eg. casamia.duckdns.org);
- la porta di connessione (tipicamente la 1194 su UDP);
- il file .ovpn relativo all’utente definito per collegarsi alla VPN;
- l’indirizzo IP della rete VPN assegnato all’utente che si collegherà (tipicamente 10.8.0.2).
Tutte queste informazioni serviranno all’host locale per collegarvisi.
FIREWALL
Ora è necessario configurare il firewall del server virtuale (continuiamo a ipotizzare di aver utilizzato Google Cloud Platform) affinché vengano accettate determinate comunicazioni dall’esterno, nello specifico:
- porta UDP 1194, per la connessione VPN;
- porta TCP 8123, per le richieste Home Assistant.
Creando la VM si sarà impostato un proprio tag di rete, dato che useremo per contrassegnare e attribuire le due regole firewall. Ipotizziamo che, come da nostra guida, sia “my-host” (non fosse quello, recarsi nei dettagli della rete della VM e scoprire quale si è impostato).
Recarsi alla voce “Rete VCP” > “Firewall” della dashboard di Google Cloud Platform e cliccare su “Crea Regola Firewall“.
Questo andrà fatto due volte, ovvero per creare le due regole distinte come segue.
- PRIMA REGOLA:
- Nome: vpn;
- Direzione del traffico: In entrata;
- Azione: Consenti;
- Destinazioni: Tag di destinazione specificati;
- Tag di destinazione: il tag relativo alla propria VM (eg. “my-host“);
- Filtro di origine: Intervalli IPv4;
- Intervalli IP di origine: 0.0.0.0/0;
- Protocolli e porte: UDP 1194.
Cliccare “salva” per salvare e applicare la regola.
- SECONDA REGOLA:
- Nome: homeassistant;
- Direzione del traffico: In entrata;
- Azione: Consenti;
- Destinazioni: Tag di destinazione specificati;
- Tag di destinazione: il tag relativo alla propria VM (eg. “my-host“);
- Filtro di origine: Intervalli IPv4;
- Intervalli IP di origine: 0.0.0.0/0;
- Protocolli e porte: TCP 8123.
Cliccare “salva” per salvare e applicare anche questa regola.
Routing
Siamo ora davanti a un bivio già precedentemente accennato, ovvero come gestire il routing del traffico dal server remoto all’host locale via tunnelling – e quindi ai servizi su di esso collocati.
Le casistiche in sostanza sono due:
- regole statiche di routing sul server remoto, di modo che tutto il traffico per una data porta venga girato così com’è verso l’host remoto, il quale poi:
- o si limita a riceverlo e a rispondere;
- oppure, in presenza di un Reverse Proxy, riceverlo e poi lo trattarlo in base alle sue regole locali;
- Reverse Proxy sul server remoto, in modo che il traffico venga rediretto miratamente verso i servizi presenti sull’host locale.
Vanno bene entrambi gli approcci, sebbene filosoficamente ci sembrerebbe più corretto installare Reverse Proxy sul server remoto. Questo approccio, però, ben più complesso, verrà semmai aggiunto a questa guida (in questo punto) in una fase successiva alla pubblicazione della stessa.
Se sin qui si sono usate le nostre guide sopracitate, e quindi si dispone di un server Linux Debian, per implementare le regole di routing statiche provvedere a quanto segue.
Collegarsi tramite SSH all’host Linux Debian ed eseguire:
sudo -s
per elevare i propri diritti utente.
Andiamo poi a creare due regole che facciano sì che il traffico delle porte 443 e 8123 venga girato in toto l’indirizzo 10.8.0.2 (l’indirizzo che verrà assegnato al client VPN dell’host locale) – in caso l’indirizzo fosse diverso (vedi sopra), correggere coerentemente ed eseguire i seguenti comandi:
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.8.0.2:443
iptables -t nat -A PREROUTING -p tcp --dport 8123 -j DNAT --to-destination 10.8.0.2:8123
iptables -t nat -A POSTROUTING -j MASQUERADE
per aggiungere le regole e infine:
iptables-save > /etc/iptables/rules.v4 exit
per salvarle.
Da qui in poi qualunque chiamata per casamia.duckdns.org:433 e casamia.duckdns.org:8123 verranno girate a 10.8.0.2, ovvero il nostro host privato.
Bene! Il nostro server remoto è operativo.
Host Locale
A questo punto è importante configurare il nostro host locale. La prima cosa da fare, ovviamente, è far sì che esso stabilisca una connessione costante in tunnelling col server remoto tramite VPN.
Collegarsi alla VPN
Per farlo, va da sé, è necessario un client in grado di collegarvisi, così come va da sé che sia impossibile documentare installazione e configurazione per qualsiasi binomio sistema operativo / client VPN. Assumendo che si siano seguite le nostre guide di cui sopra, il cerchio si restringe: è sufficiente capire come collegare il proprio host locale al server remoto tramite OpenVPN Client.
Diversamente, bisognerà documentarsi in merito al client/server VPN scelto.
Alcune nostre guide utili alla configurazione di OpenVPN Client sono:
- Collegare Mini PC/Intel NUC/computer a una VPN con OpenVPN Client, Linux Debian e Docker;
- Collegare Raspberry Pi a una VPN con OpenVPN Client, Raspberry Pi OS e Docker;
- Collegare Raspberry Pi a una VPN con OpenVPN Client, Raspberry Pi OS;
- Collegare Home Assistant OS/Supervised a una VPN con OpenVPN Client.
Quindi: quale che sia il sistema operativo, per proseguire oltre si assume che l’utente riesca a collegare il proprio host locale con il server remoto via VPN.
Home Assistant
Arrivati a questo punto abbiamo un server remoto che risponde all’indirizzo casamia.duckdns.org e che gira le chiamate per la porta 8123 al nostro host locale.
Se abbiamo scelto la strada di utilizzare regole di routing statiche, il traffico viene semplicemente girato alla porta 8123 dell’host locale, quale dovrebbe quindi già da ora rispondere all’indirizzo:
http://casamia.duckdns.org:8123
ma, ovviamente, noi vogliamo anche che l’host risponda piuttosto all’indirizzo:
https://casamia.duckdns.org:8123
ovvero supportando i certificati sicuri e quindi il supporto SSL. Per farlo è necessario configurare il servizio di Reverse Proxy sull’host che ospita Home Assistant. Terminata tale configurazione (che prevede il funzionamento del Reverse Proxy e una riconfigurazione di Home Assistant), l’indirizzo https comincerà a funzionare.
Se invece abbiamo scelto la strada di installare il Reverse Proxy sul server remoto, lato host locale sarà solo necessario una semplice riconfigurazione di Home Assistant.
|
⚠️ 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. |