Home Assistant funziona tramite Wi-Fi, ma non tramite Ethernet o VPN

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Home Assistant Works on Wi-Fi but Fails on Ethernet or VPN

Quando Home Assistant funziona tramite Wi-Fi ma non tramite Ethernet o VPN, l'applicazione è probabilmente sana; il problema di solito riguarda lo stato del collegamento, l'indirizzamento, le route, le policy, il DNS, il traffico di ritorno o il rilevamento multicast.

Mantieni disponibile il percorso Wi-Fi funzionante mentre testi separatamente Ethernet e VPN. Per prima cosa usa l'IP diretto dell'interfaccia di destinazione, poi verifica il gateway e la route di ritorno, quindi testa la porta del servizio, il nome host e il rilevamento. Modificare più livelli di rete contemporaneamente può bloccarti fuori dal sistema e rende impossibile attribuire correttamente un risultato positivo.

Verifica che l'interfaccia Ethernet disponga di un indirizzo utilizzabile

Controlla il collegamento fisico, la velocità negoziata, lo stato dell'interfaccia, l'indirizzo assegnato, la subnet, il gateway e il lease DHCP dall'host di Home Assistant o dall'hypervisor. Confrontali con quelli di un client funzionante sulla stessa rete Ethernet. Le sole spie del collegamento non dimostrano che la configurazione di livello 3 sia corretta.

Un caso della community consiglia di ispezionare tutte le interfacce con nmcli quando il dispositivo eth0 previsto non era presente. Il primo test utile consiste nel verificare il nome e l'indirizzo effettivi dell'interfaccia, senza presumere che ogni piattaforma chiami eth0 la propria porta cablata.

Da un client sulla stessa subnet, esegui un ping o testa in altro modo direttamente l'IP Ethernet e la porta 8123 aperta. Se l'IP non è raggiungibile, continua a verificare collegamento, VLAN, DHCP e subnet. Se l'IP funziona ma il nome host non funziona, il servizio Ethernet è sano e il DNS diventa il ramo successivo dell'analisi.

Controlla la scelta della route, le policy del firewall e il traffico di ritorno

Ispeziona la tabella di routing mentre Wi-Fi ed Ethernet sono attivi. Individua la route predefinita, le metriche delle interfacce e la route di ritorno verso il client di test o la subnet VPN. Le risposte che escono dall'interfaccia sbagliata possono far sembrare bloccate le connessioni in ingresso anche quando la richiesta è arrivata.

Esegui temporaneamente il test dalla stessa VLAN prima di attraversare le policy del router. Se l'accesso nella stessa subnet funziona ma quello instradato non funziona, controlla le regole del firewall tra VLAN, la modalità di rete del container, il bridge dell'hypervisor, le reti consentite dalla VPN e la route inversa sul lato di Home Assistant.

Il confronto di ZimaSpace tra rete host e rete bridge aiuta a distinguere un limite della porta del container o del rilevamento da un guasto fisico Ethernet. Mantieni il percorso Wi-Fi funzionante finché il percorso cablato non supera il test in modo indipendente.

Separa la raggiungibilità diretta dal DNS e dal rilevamento

Esegui i test in quest'ordine: IP Ethernet o VPN, porta del servizio, nome host configurato e infine rilevamento automatico. Se l'accesso tramite IP diretto funziona ma quello tramite nome host non funziona, il problema riguarda il DNS o un indirizzo memorizzato nella cache non più valido. Se l'interfaccia web è accessibile direttamente ma mancano i dispositivi, il problema riguarda invece il rilevamento o la policy della subnet dei dispositivi.

Le discussioni su Home Assistant tra subnet mostrano che la risoluzione mDNS può non funzionare anche quando il normale traffico unicast è consentito, perché il rilevamento multicast richiede un inoltro esplicito o un reflector. Questa distinzione tra multicast e unicast è particolarmente importante nelle VLAN e nelle VPN instradate.

Non ampliare tutte le regole del firewall solo per far comparire il rilevamento. Quando supportato, preferisci indirizzi espliciti per le integrazioni oppure configura un relay multicast con ambito ristretto tra segmenti attendibili. Se l'interfaccia web non è raggiungibile nemmeno tramite IP diretto, il rilevamento non è ancora il problema da risolvere.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Applica una sola correzione di rete e ripeti tutti i test

Correggi esclusivamente il livello confermato: cavo o porta dello switch, prenotazione DHCP, subnet o gateway, metrica dell'interfaccia, regola del firewall, route di ritorno, record DNS, rete consentita dalla VPN o relay multicast. Salva la configurazione precedente e predisponi un metodo di accesso locale prima di riavviare i servizi di rete.

Ripeti i test sull'IP Ethernet, sul nome host, sui dispositivi locali, sul client VPN, sull'interfaccia web remota, sulla stabilità del WebSocket e sul rilevamento nello stesso ordine. Riavvia l'host una volta e rinnova lo stato di rete del client, così le route e il DNS obsoleti non creano un successo temporaneo.

Un risultato positivo mantiene un accesso Ethernet affidabile, conserva la route VPN prevista, evita percorsi predefiniti duplicati e consente il rilevamento solo attraverso i confini approvati. Esegui il rollback se il percorso Wi-Fi funzionante scompare o se il traffico fuoriesce tra i segmenti; fornisci dati su interfacce, route, firewall e flusso dei pacchetti quando le richieste arrivano ma le risposte continuano a uscire in modo errato.