Home Assistant funktioniert über WLAN, aber nicht über Ethernet oder VPN

Wenn Home Assistant über WLAN funktioniert, aber über Ethernet oder VPN ausfällt, ist die Anwendung wahrscheinlich intakt. Die Ursache liegt meist im Link-Status, bei der Adressierung, in Routen, Richtlinien, DNS, Rückverkehr oder der Multicast-Erkennung.

Halten Sie den bekannten funktionierenden WLAN-Pfad verfügbar, während Sie Ethernet und VPN getrennt testen. Verwenden Sie zuerst die direkte IP-Adresse der Ziel-Schnittstelle, prüfen Sie anschließend Gateway und Rückroute und testen Sie danach den Dienst-Port, den Hostnamen und die Erkennung. Wenn Sie mehrere Netzwerkschichten gleichzeitig ändern, können Sie sich aussperren, und ein erfolgreiches Ergebnis lässt sich nicht mehr eindeutig zuordnen.

Nachweisen, dass die Ethernet-Schnittstelle eine nutzbare Adresse besitzt

Prüfen Sie am Home-Assistant-Host oder Hypervisor den physischen Link, die ausgehandelte Geschwindigkeit, den Schnittstellenstatus, die zugewiesene Adresse, das Subnetz, das Gateway und das DHCP-Lease. Vergleichen Sie diese Angaben mit einem funktionierenden Client im selben Ethernet-Netzwerk. Link-LEDs allein weisen keine korrekte Layer-3-Konfiguration nach.

Ein Community-Fall empfiehlt, mit nmcli alle Schnittstellen zu prüfen, wenn das erwartete Gerät eth0 nicht vorhanden war. Der erste sinnvolle Test gilt dem tatsächlichen Schnittstellennamen und der tatsächlichen Adresse, statt davon auszugehen, dass jede Plattform ihren kabelgebundenen Port eth0 nennt.

Starten Sie von einem Client im selben Subnetz einen Ping oder testen Sie auf andere Weise die Ethernet-IP-Adresse und den offenen Port 8123 direkt. Wenn die IP-Adresse nicht erreichbar ist, bleiben Sie bei der Prüfung von Link, VLAN, DHCP und Subnetz. Wenn die IP-Adresse funktioniert, der Hostname jedoch fehlschlägt, ist der Ethernet-Dienst intakt und DNS der nächste Ansatzpunkt.

Routenwahl, Firewall-Richtlinien und Rückverkehr prüfen

Untersuchen Sie die Routing-Tabelle, während WLAN und Ethernet gleichzeitig aktiv sind. Ermitteln Sie die Standardroute, die Schnittstellenmetriken und die Route zurück zum Test-Client oder VPN-Subnetz. Antworten, die über die falsche Schnittstelle gesendet werden, können eingehende Verbindungen wie blockiert erscheinen lassen, selbst wenn die Anfrage angekommen ist.

Testen Sie vorübergehend aus demselben VLAN, bevor Sie Router-Richtlinien überschreiten. Wenn der Zugriff im selben Subnetz funktioniert, über geroutete Verbindungen jedoch fehlschlägt, prüfen Sie Inter-VLAN-Firewall-Regeln, den Netzwerkmodus des Containers, die Hypervisor-Bridge, erlaubte VPN-Netzwerke und die Rückroute auf der Home-Assistant-Seite.

Der Vergleich von Host- und Bridge-Netzwerken bei ZimaSpace hilft dabei, die Grenze zwischen Container-Port oder Erkennung und einem physischen Ethernet-Fehler zu unterscheiden. Behalten Sie die funktionierende WLAN-Route bei, bis der kabelgebundene Pfad unabhängig funktioniert.

Direkte Erreichbarkeit von DNS und Erkennung unterscheiden

Testen Sie in dieser Reihenfolge: Ethernet- oder VPN-IP-Adresse, Dienst-Port, konfigurierter Hostname und anschließend die automatische Erkennung. Wenn der direkte Zugriff per IP funktioniert, der Hostname jedoch nicht, deutet dies auf DNS oder eine veraltete zwischengespeicherte Adresse hin. Wenn die direkte Benutzeroberfläche funktioniert, aber Geräte fehlen, liegt die Ursache stattdessen bei der Erkennung oder den Richtlinien für das Gerätesubnetz.

Diskussionen zu Home Assistant über Subnetzgrenzen hinweg zeigen, dass die mDNS-Auflösung fehlschlagen kann, obwohl gewöhnlicher Unicast-Datenverkehr erlaubt ist, da die Multicast-Erkennung eine gezielte Weiterleitung oder einen Reflector benötigt. Dieser Unterschied zwischen Multicast und Unicast ist besonders über VLANs und geroutete VPNs wichtig.

Erweitern Sie nicht einfach jede Firewall-Regel, damit die Erkennung funktioniert. Bevorzugen Sie, sofern unterstützt, ausdrücklich angegebene Integrationsadressen oder konfigurieren Sie ein eng begrenztes Multicast-Relay zwischen vertrauenswürdigen Segmenten. Wenn die Benutzeroberfläche selbst über die direkte IP-Adresse nicht erreichbar ist, ist die Erkennung noch nicht der relevante Lösungsansatz.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Eine Netzwerkänderung anwenden und jeden Pfad erneut testen

Beheben Sie ausschließlich die bestätigte Schicht: Kabel oder Switch-Port, DHCP-Reservierung, Subnetz oder Gateway, Schnittstellenmetrik, Firewall-Regel, Rückroute, DNS-Eintrag, erlaubtes VPN-Netzwerk oder Multicast-Relay. Sichern Sie die vorherige Konfiguration und richten Sie vor dem Neustart von Netzwerkdiensten eine lokale Zugriffsmöglichkeit ein.

Testen Sie erneut die Ethernet-IP-Adresse, den Hostnamen, lokale Geräte, den VPN-Client, die entfernte Benutzeroberfläche, die WebSocket-Stabilität und die Erkennung – in derselben Reihenfolge. Starten Sie den Host einmal neu und erneuern Sie den Netzwerkstatus der Clients, damit veraltete Routen und DNS-Einträge keinen vorübergehenden Erfolg vortäuschen.

Ein erfolgreiches Ergebnis gewährleistet zuverlässigen Ethernet-Zugriff, behält die vorgesehene VPN-Route bei, vermeidet doppelte Standardrouten und erkennt Geräte nur über genehmigte Grenzen hinweg. Führen Sie ein Rollback durch, wenn der funktionierende WLAN-Pfad verschwindet oder Datenverkehr zwischen Segmenten durchsickert. Eskalieren Sie das Problem mit Informationen zu Schnittstellen, Routen, Firewall und Paketfluss, wenn Anfragen ankommen, Antworten jedoch weiterhin über die falsche Schnittstelle gesendet werden.