Home Assistant fungerar via Wi-Fi men inte via Ethernet eller VPN

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

När Home Assistant fungerar via Wi-Fi men inte via Ethernet eller VPN är programmet troligen friskt; felet ligger vanligtvis i länkstatus, adressering, routing, policy, DNS, returtrafik eller multicastupptäckt.

Behåll den fungerande Wi-Fi-vägen tillgänglig medan du testar Ethernet och VPN separat. Använd först målgränssnittets direkta IP-adress, verifiera sedan gateway och returroute och testa därefter tjänstens port, värdnamn och upptäckt. Om du ändrar flera nätverkslager samtidigt kan du låsa ute dig själv och det blir omöjligt att avgöra vad som gav ett lyckat resultat.

Verifiera att Ethernet-gränssnittet har en användbar adress

Kontrollera fysisk länk, förhandlad hastighet, gränssnittets status, tilldelad adress, subnät, gateway och DHCP-leasing från Home Assistant-värden eller hypervisorn. Jämför dem med en fungerande klient på samma Ethernet-nätverk. Länkindikatorer bevisar inte i sig att lager 3-konfigurationen är korrekt.

Ett communityfall rekommenderar att inspektera alla gränssnitt med nmcli när den förväntade eth0-enheten saknades. Det användbara första testet är det faktiska gränssnittsnamnet och adressen, inte att anta att alla plattformar kallar sin trådbundna port eth0.

Från en klient på samma subnät kan du pinga eller på annat sätt testa Ethernet-IP-adressen och den öppna porten 8123 direkt. Om IP-adressen inte går att nå ska du fortsätta kontrollera länk, VLAN, DHCP och subnät. Om IP-adressen fungerar men värdnamnet inte gör det är Ethernet-tjänsten frisk och DNS blir nästa område att undersöka.

Kontrollera ruttval, brandväggspolicy och returtrafik

Inspektera routingtabellen när både Wi-Fi och Ethernet är aktiva. Identifiera standardrutten, gränssnittsmetrikerna och rutten tillbaka till testklienten eller VPN-subnätet. Svar som lämnar systemet via fel gränssnitt kan få inkommande anslutningar att verka blockerade även när begäran nådde fram.

Testa tillfälligt från samma VLAN innan du passerar routerpolicyer. Om åtkomst inom samma subnät fungerar men routad åtkomst misslyckas ska du kontrollera brandväggsregler mellan VLAN, containerns nätverksläge, hypervisorbryggan, VPN-tillåtna nätverk och den omvända rutten på Home Assistant-sidan.

ZimaSpaces jämförelse av värd- och bryggnätverk hjälper dig att skilja en gräns för containerport eller upptäckt från ett fysiskt Ethernet-fel. Behåll den fungerande Wi-Fi-rutten tills den trådbundna vägen fungerar självständigt.

Skilj direkt nåbarhet från DNS och upptäckt

Testa i denna ordning: Ethernet- eller VPN-IP, tjänsteport, konfigurerat värdnamn och därefter automatisk upptäckt. Om direkt åtkomst via IP fungerar men värdnamnet inte gör det pekar det på DNS eller en gammal cachad adress. Om det direkta användargränssnittet fungerar men enheter saknas pekar det i stället på upptäckt eller policy för enhetens subnät.

Diskussioner om Home Assistant över flera subnät visar att mDNS-upplösning kan misslyckas även när vanlig unicasttrafik är tillåten, eftersom multicastupptäckt kräver avsiktlig vidarebefordran eller en reflektor. Denna skillnad mellan multicast och unicast är särskilt viktig över VLAN och routade VPN-anslutningar.

Bredda inte alla brandväggsregler bara för att få upptäckt att fungera. Föredra uttryckliga integrationsadresser när det stöds, eller konfigurera en snävt avgränsad multicastreläfunktion mellan betrodda segment. Om själva användargränssnittet inte går att nå via direkt IP är upptäckt ännu inte den relevanta åtgärden.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Tillämpa en nätverksåtgärd i taget och testa alla vägar igen

Korrigera endast det bekräftade lagret: kabel eller switchport, DHCP-reservation, subnät eller gateway, gränssnittsmått, brandväggsregel, returroute, DNS-post, VPN-tillåtet nätverk eller multicastrelä. Spara den tidigare konfigurationen och planera en lokal åtkomstmetod innan du startar om nätverkstjänster.

Testa Ethernet-IP-adressen, värdnamnet, lokala enheter, VPN-klienten, det fjärranslutna användargränssnittet, WebSocket-stabiliteten och upptäckten igen i samma ordning. Starta om värden en gång och förnya klientens nätverkstillstånd så att gamla rutter och DNS-poster inte skapar ett tillfälligt lyckat resultat.

Ett godkänt resultat innebär att Ethernet-åtkomsten är tillförlitlig, att den avsedda VPN-rutten finns kvar, att dubbla standardvägar undviks och att upptäckt endast sker över godkända gränser. Återställ ändringen om den fungerande Wi-Fi-vägen försvinner eller trafik läcker mellan segment; eskalera med bevis på gränssnitt, rutter, brandvägg och paketflöde när begäranden når fram men svaren fortfarande lämnar systemet felaktigt.