Home Assistant werkt via wifi, maar niet via ethernet of VPN

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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

Wanneer Home Assistant via wifi werkt maar via Ethernet of VPN faalt, is de applicatie waarschijnlijk in orde; de fout zit meestal in de linkstatus, adressering, routes, beleid, DNS, retourverkeer of multicastdetectie.

Houd het bekende werkende wifipad beschikbaar terwijl je Ethernet en VPN afzonderlijk test. Gebruik eerst het directe IP-adres van de doelinterface, controleer daarna de gateway en retourroute en test vervolgens de servicepoort, hostnaam en detectie. Door meerdere netwerklagen tegelijk te wijzigen, kun je jezelf buitensluiten en wordt het onmogelijk om een geslaagd resultaat aan één oorzaak toe te schrijven.

Bewijs dat de Ethernetinterface een bruikbaar adres heeft

Controleer vanaf de Home Assistant-host of hypervisor de fysieke verbinding, onderhandelde snelheid, interfacestatus, toegewezen adres, subnet, gateway en DHCP-lease. Vergelijk deze gegevens met een werkende client op hetzelfde Ethernetnetwerk. Brandende linklampjes bewijzen op zichzelf geen correcte Layer 3-configuratie.

Een communitygeval raadt aan alle interfaces met nmcli te inspecteren toen het verwachte eth0-apparaat ontbrak. De nuttige eerste test is de werkelijke interfacenaam en het bijbehorende adres, en niet ervan uitgaan dat elk platform zijn bedrade poort eth0 noemt.

Ping vanaf een client op hetzelfde subnet het Ethernet-IP-adres of test dit op een andere manier, en controleer poort 8123 rechtstreeks. Als het IP-adres onbereikbaar is, blijf dan bij controles van de verbinding, VLAN, DHCP en het subnet. Als het IP-adres werkt maar de hostnaam niet, is de Ethernetservice gezond en is DNS de volgende onderzoekstak.

Controleer routekeuze, firewallbeleid en retourverkeer

Inspecteer de routingtabel terwijl wifi en Ethernet beide actief zijn. Bepaal de standaardroute, interfacemetrieken en de route terug naar de testclient of het VPN-subnet. Antwoorden die via de verkeerde interface vertrekken, kunnen inkomende verbindingen geblokkeerd laten lijken, zelfs wanneer het verzoek is aangekomen.

Test tijdelijk vanuit hetzelfde VLAN voordat je routerbeleid doorkruist. Als toegang binnen hetzelfde subnet werkt maar gerouteerde toegang faalt, controleer dan inter-VLAN-firewallregels, de netwerkmodus van de container, de bridge van de hypervisor, toegestane VPN-netwerken en de retourroute aan de Home Assistant-kant.

De vergelijking van ZimaSpace tussen host- en bridgenetwerken helpt onderscheid te maken tussen een containerpoort of detectiegrens en een fysieke Ethernetfout. Behoud de werkende wifiroute totdat het bekabelde pad zelfstandig is geslaagd.

Scheid directe bereikbaarheid van DNS en detectie

Test in deze volgorde: Ethernet- of VPN-IP-adres, servicepoort, geconfigureerde hostnaam en daarna automatische detectie. Als een direct IP-adres werkt maar de hostnaam niet, wijst dat op DNS of een verouderd gecachet adres. Als de directe gebruikersinterface werkt maar apparaten ontbreken, ligt het probleem eerder bij detectie of beleid voor apparaatsubnets.

Discussies over Home Assistant tussen subnetten laten zien dat mDNS-resolutie kan falen, zelfs wanneer normaal unicastverkeer is toegestaan, omdat multicastdetectie doelbewuste doorsturing of een reflector nodig heeft. Dit onderscheid tussen multicast en unicast is vooral belangrijk bij VLAN's en gerouteerde VPN's.

Maak niet elke firewallregel ruimer om detectie te laten werken. Gebruik liever expliciete integratieadressen wanneer die worden ondersteund, of configureer een beperkt afgebakende multicastrelay tussen vertrouwde segmenten. Als de gebruikersinterface zelf via het directe IP-adres onbereikbaar is, is detectie nog niet de relevante oplossing.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Pas één netwerkoplossing toe en test elk pad opnieuw

Corrigeer alleen de bevestigde laag: kabel of switchpoort, DHCP-reservering, subnet of gateway, interfacemetriek, firewallregel, retourroute, DNS-record, toegestaan VPN-netwerk of multicastrelay. Sla de vorige configuratie op en regel een lokale toegangsoptie voordat je netwerkservices opnieuw start.

Test het Ethernet-IP-adres, de hostnaam, lokale apparaten, de VPN-client, de externe gebruikersinterface, WebSocket-stabiliteit en detectie opnieuw in dezelfde volgorde. Start de host één keer opnieuw op en vernieuw de netwerkstatus van clients, zodat verouderde routes en DNS-gegevens geen tijdelijk succes veroorzaken.

Een geslaagd resultaat behoudt betrouwbare Ethernettoegang, handhaaft de bedoelde VPN-route, voorkomt dubbele standaardroutes en detecteert uitsluitend over goedgekeurde grenzen heen. Zet de wijziging terug als het werkende wifipad verdwijnt of verkeer tussen segmenten lekt; escaleer met gegevens over interface, route, firewall en pakketstromen wanneer verzoeken aankomen maar antwoorden nog steeds via de verkeerde weg vertrekken.