Home Assistant dovrebbe usare una rete host o una rete bridge?

Home Assistant dovrebbe usare la rete dell’host quando la rilevazione sulla LAN è indispensabile; la rete bridge è preferibile quando sono più importanti le porte esplicite e l’isolamento.

Nessuna delle due modalità è universalmente più veloce o più sicura. La scelta modifica lo spazio dei nomi di rete visibile a Home Assistant, il modo in cui la rilevazione multicast e broadcast lo raggiunge, le porte pubblicate e il modo in cui gli altri container si connettono. Decidi in base alle integrazioni che devono funzionare dopo un riavvio, quindi testa la rilevazione, il controllo diretto, i gateway MQTT o radio e l’accesso remoto in ingresso nella modalità scelta prima di considerare stabile la configurazione.

Verifica innanzitutto se Home Assistant deve ricevere il traffico di rilevazione dalla LAN

Molte integrazioni di Home Assistant possono usare un indirizzo IP noto o una connessione a un broker, ma altre dipendono dalla rilevazione tramite mDNS, SSDP, UPnP o broadcast. Questi protocolli sono il motivo principale per cui la rete dell’host è comune nelle installazioni Container: Home Assistant partecipa direttamente allo spazio dei nomi LAN dell’host invece di richiedere l’inoltro multicast attraverso un bridge Docker.

Una guida al networking Docker spiega che la rete dell’host elimina il confine del bridge, rendendo più semplici i servizi basati sul broadcast, ma rimuovendo anche la pubblicazione delle porte Docker e la separazione degli spazi dei nomi di rete. Per la maggior parte delle installazioni di Home Assistant, questo compromesso è più rilevante delle prestazioni pure.

Elenca le integrazioni che richiedono effettivamente la rilevazione. Se ogni dispositivo critico usa indirizzi espliciti, MQTT, Zigbee tramite un coordinatore mappato o un altro endpoint ben definito, la modalità bridge può funzionare senza problemi. Se diverse integrazioni dipendono dalla rilevazione locale e non vuoi gestire relay multicast, la modalità host è solitamente la scelta operativa più semplice.

La rete dell’host è adatta quando la semplicità della rilevazione prevale sull’isolamento dello spazio dei nomi

In modalità host, Home Assistant si collega direttamente allo stack di rete dell’host. Non esiste un livello di mappatura delle porte Docker e il container vede le interfacce dell’host in un modo che generalmente si adatta meglio alla rilevazione locale. Il costo è un isolamento di rete più debole e la necessità di gestire i conflitti tra porte a livello dell’host.

Un’analisi della progettazione di Home Assistant in Docker arriva alla stessa conclusione condizionale: la modalità host semplifica la rilevazione mDNS e UPnP, mentre la modalità bridge rende più espliciti i confini di rete e le porte pubblicate.

Scegli la modalità host quando i problemi di rilevazione si ripresentano e il server è un host domestico affidabile con un insieme di servizi controllato. Non usare la modalità host soltanto per nascondere un problema di connettività non identificato. Se un dispositivo continua a non funzionare con la rete dell’host, la causa potrebbe essere nelle regole VLAN, nell’isolamento dei client Wi-Fi, nel DNS locale, nei permessi del dispositivo o in un problema a livello di integrazione, non nel bridge Docker.

La rete bridge è adatta quando le integrazioni hanno una raggiungibilità esplicita

La modalità bridge assegna al container un indirizzo Docker privato e consente di pubblicare solo le porte di Home Assistant che devono essere raggiungibili. Gli altri container possono comunicare tramite reti Docker denominate, mentre i dispositivi LAN raggiungono la porta dell’host pubblicata. È un confine più pulito quando la rilevazione non è essenziale o quando inoltri deliberatamente il traffico multicast tramite un proxy.

Gli utenti di Home Assistant che confrontano le configurazioni bridge e macvlan riferiscono che il bridge semplice può complicare mDNS, mentre progettazioni di rete alternative ripristinano la visibilità diretta sulla LAN. La lezione utile di rilevazione nella rete bridge è testare il protocollo necessario invece di presumere che le porte TCP pubblicate trasportino anche la rilevazione multicast.

Scegli la modalità bridge quando i dispositivi necessari sono raggiungibili tramite IP esplicito, hostname, broker o percorso hardware mappato e vuoi confini più rigidi tra i servizi. Se un’integrazione fallisce solo perché non riesce a rilevare un dispositivo LAN, prova innanzitutto a configurare esplicitamente l’endpoint. Passa alla modalità host o a una rete più avanzata solo quando l’integrazione richiede davvero quel comportamento di rilevazione.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Convalida la scelta con la stessa matrice di integrazioni dopo un riavvio

Prepara un test in cinque righe: accesso alla dashboard locale, un dispositivo mDNS o SSDP, un’integrazione con IP esplicito, un broker o gateway radio e il normale percorso tramite reverse proxy o VPN. Esegui il test dopo aver ricreato il container e dopo aver riavviato l’host, non solo subito dopo aver modificato Compose, perché la rilevazione memorizzata nella cache può nascondere una modalità di rete destinata a fallire in seguito.

L’analisi di ZimaSpace sulla raggiungibilità delle subnet Docker dimostra lo stesso confine: la disponibilità dell’applicazione e la raggiungibilità della rete del container sono verifiche diverse, anche quando entrambe risiedono sullo stesso server fisico.

Mantieni la modalità host quando preserva costantemente la rilevazione necessaria e accetti lo spazio dei nomi condiviso. Mantieni la modalità bridge quando ogni integrazione richiesta rimane raggiungibile e il confine esplicito riduce l’ambiguità operativa. Se nessuna delle due supera i test, smetti di cambiare modalità e controlla il routing VLAN, l’inoltro multicast, le regole firewall o il trasporto dell’integrazione stessa; la modalità di rete è solo uno dei livelli del percorso.