Home Assistant fonctionne en Wi-Fi, mais échoue en Ethernet ou via VPN

Lorsque Home Assistant fonctionne en Wi-Fi, mais échoue en Ethernet ou via un VPN, l’application est probablement saine ; le problème se situe généralement au niveau de l’état de la liaison, de l’adressage, des routes, des règles, du DNS, du trafic de retour ou de la découverte multidiffusion.

Conservez le chemin Wi-Fi connu comme fonctionnel pendant que vous testez séparément l’Ethernet et le VPN. Commencez par utiliser l’adresse IP directe de l’interface cible, puis vérifiez la passerelle et la route de retour, avant de tester le port du service, le nom d’hôte et la découverte. Modifier plusieurs couches réseau en même temps peut vous bloquer et empêche d’attribuer clairement la réussite à une cause précise.

Vérifiez que l’interface Ethernet possède une adresse utilisable

Vérifiez la liaison physique, la vitesse négociée, l’état de l’interface, l’adresse attribuée, le sous-réseau, la passerelle et le bail DHCP depuis l’hôte Home Assistant ou l’hyperviseur. Comparez-les avec ceux d’un client fonctionnel sur le même réseau Ethernet. Les voyants de liaison ne suffisent pas à prouver que la configuration de couche 3 est correcte.

Un cas rapporté par la communauté recommande d’inspecter toutes les interfaces avec nmcli lorsque le périphérique eth0 attendu était absent. Le premier test utile consiste à vérifier le nom et l’adresse réels de l’interface, plutôt que de supposer que chaque plateforme appelle son port filaire eth0.

Depuis un client situé sur le même sous-réseau, envoyez une requête ping ou testez d’une autre manière l’adresse IP Ethernet et le port 8123 ouvert directement. Si l’adresse IP est inaccessible, poursuivez les vérifications de la liaison, du VLAN, du DHCP et du sous-réseau. Si l’adresse IP fonctionne, mais que le nom d’hôte échoue, le service Ethernet est sain et le DNS devient la prochaine piste.

Vérifiez le choix de route, les règles du pare-feu et le trafic de retour

Inspectez la table de routage lorsque le Wi-Fi et l’Ethernet sont actifs simultanément. Identifiez la route par défaut, les métriques des interfaces et la route de retour vers le client de test ou le sous-réseau VPN. Des réponses envoyées par la mauvaise interface peuvent donner l’impression que les connexions entrantes sont bloquées, même si la requête est bien arrivée.

Effectuez temporairement les tests depuis le même VLAN avant de traverser les règles du routeur. Si l’accès fonctionne sur le même sous-réseau, mais échoue via le routage, inspectez les règles du pare-feu inter-VLAN, le mode réseau du conteneur, le pont de l’hyperviseur, les réseaux autorisés par le VPN et la route inverse du côté de Home Assistant.

La comparaison proposée par ZimaSpace entre la mise en réseau hôte et pontée aide à distinguer une limitation liée au port du conteneur ou à la découverte d’une défaillance de l’Ethernet physique. Conservez la route Wi-Fi fonctionnelle jusqu’à ce que le chemin filaire passe ses tests indépendamment.

Distinguez l’accessibilité directe du DNS et de la découverte

Effectuez les tests dans cet ordre : adresse IP Ethernet ou VPN, port du service, nom d’hôte configuré, puis découverte automatique. Si l’accès par IP directe fonctionne, mais que l’accès par nom d’hôte échoue, le problème vient probablement du DNS ou d’une adresse mise en cache obsolète. Si l’interface est accessible directement, mais que des appareils sont absents, le problème concerne plutôt la découverte ou les règles applicables au sous-réseau des appareils.

Les discussions consacrées à Home Assistant entre sous-réseaux montrent que la résolution mDNS peut échouer même lorsque le trafic monodiffusion ordinaire est autorisé, car la découverte multidiffusion nécessite un transfert explicite ou un réflecteur. Cette distinction entre multidiffusion et monodiffusion est particulièrement importante sur les VLAN et les VPN routés.

N’élargissez pas toutes les règles du pare-feu simplement pour faire apparaître la découverte. Préférez des adresses d’intégration explicites lorsque cette possibilité est prise en charge, ou configurez un relais multidiffusion limité entre des segments de confiance. Si l’interface elle-même est inaccessible par IP directe, la découverte n’est pas encore la bonne piste de résolution.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Appliquez une seule correction réseau, puis testez à nouveau tous les chemins

Corrigez uniquement la couche confirmée : câble ou port du commutateur, réservation DHCP, sous-réseau ou passerelle, métrique de l’interface, règle du pare-feu, route de retour, enregistrement DNS, réseau autorisé par le VPN ou relais multidiffusion. Enregistrez la configuration précédente et prévoyez un moyen d’accès local avant de redémarrer les services réseau.

Retestez l’adresse IP Ethernet, le nom d’hôte, les appareils locaux, le client VPN, l’interface distante, la stabilité du WebSocket et la découverte dans le même ordre. Redémarrez l’hôte une fois et renouvelez l’état réseau des clients afin que des routes ou des entrées DNS obsolètes ne créent pas une réussite temporaire.

Une résolution réussie conserve un accès Ethernet fiable, maintient la route VPN prévue, évite les chemins par défaut en double et n’effectue la découverte qu’entre les limites autorisées. Annulez les changements si le chemin Wi-Fi fonctionnel disparaît ou si du trafic fuit entre les segments ; transmettez les éléments relatifs à l’interface, aux routes, au pare-feu et au flux des paquets lorsque les requêtes arrivent, mais que les réponses continuent de partir par la mauvaise route.