O Home Assistant funciona por Wi-Fi, mas falha através de Ethernet ou VPN

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

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

Quando o Home Assistant funciona por Wi-Fi, mas falha por Ethernet ou VPN, a aplicação está provavelmente saudável; a falha costuma estar no estado da ligação, no endereçamento, nas rotas, na política, no DNS, no tráfego de retorno ou na descoberta multicast.

Mantenha disponível o percurso Wi-Fi conhecido como funcional enquanto testa a Ethernet e a VPN separadamente. Primeiro, utilize o IP direto da interface pretendida; depois, verifique o gateway e a rota de retorno; em seguida, teste a porta do serviço, o nome de anfitrião e a descoberta. Alterar várias camadas de rede em simultâneo pode bloquear o acesso e impossibilita atribuir um resultado bem-sucedido a uma causa específica.

Comprove que a Interface Ethernet Tem um Endereço Utilizável

Verifique a ligação física, a velocidade negociada, o estado da interface, o endereço atribuído, a sub-rede, o gateway e a concessão DHCP a partir do anfitrião do Home Assistant ou do hipervisor. Compare-os com um cliente funcional na mesma rede Ethernet. As luzes de ligação, por si só, não comprovam uma configuração correta da Camada 3.

Um caso da comunidade recomenda inspecionar todas as interfaces com o nmcli quando o dispositivo eth0 esperado estava ausente. O primeiro teste útil é o nome e endereço reais da interface, em vez de presumir que todas as plataformas chamam eth0 à respetiva porta com fios.

A partir de um cliente na mesma sub-rede, faça ping ou teste de outra forma o IP Ethernet e a porta 8123 diretamente. Se o IP estiver inacessível, continue a verificar a ligação, a VLAN, o DHCP e a sub-rede. Se o IP funcionar, mas o nome de anfitrião falhar, o serviço Ethernet está saudável e o DNS passa a ser o próximo ramo da investigação.

Verifique a Escolha de Rotas, a Política da Firewall e o Tráfego de Retorno

Inspecione a tabela de encaminhamento enquanto o Wi-Fi e a Ethernet estão ativos. Identifique a rota predefinida, as métricas das interfaces e a rota de retorno para o cliente de teste ou para a sub-rede VPN. As respostas que saem pela interface errada podem fazer com que as ligações recebidas pareçam bloqueadas, mesmo quando o pedido chegou.

Teste temporariamente a partir da mesma VLAN antes de atravessar políticas de encaminhamento. Se o acesso na mesma sub-rede funcionar, mas o acesso encaminhado falhar, inspecione as regras da firewall entre VLANs, o modo de rede do contentor, a bridge do hipervisor, as redes permitidas pela VPN e a rota inversa do lado do Home Assistant.

A comparação da ZimaSpace entre rede no modo anfitrião e no modo bridge ajuda a distinguir um limite da porta do contentor ou da descoberta de uma falha física na Ethernet. Mantenha o percurso Wi-Fi funcional até o percurso com fios passar o teste de forma independente.

Separe a Acessibilidade Direta do DNS e da Descoberta

Teste pela seguinte ordem: IP da Ethernet ou da VPN, porta do serviço, nome de anfitrião configurado e, por fim, descoberta automática. Um acesso direto por IP bem-sucedido com falha no nome de anfitrião aponta para o DNS ou para um endereço antigo em cache. Um acesso direto à interface bem-sucedido com dispositivos em falta aponta, em vez disso, para a descoberta ou para a política da sub-rede dos dispositivos.

Discussões sobre o Home Assistant entre sub-redes mostram que a resolução mDNS pode falhar mesmo quando o tráfego unicast normal é permitido, porque a descoberta multicast requer encaminhamento deliberado ou um reflector. Esta distinção entre multicast e unicast é especialmente importante em VLANs e VPNs encaminhadas.

Não alargue todas as regras da firewall apenas para fazer a descoberta funcionar. Prefira endereços explícitos das integrações, quando suportados, ou configure um relay multicast com âmbito restrito entre segmentos de confiança. Se a própria interface estiver inacessível por IP direto, a descoberta ainda não é a correção relevante.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Aplique Uma Correção de Rede e Teste Novamente Todos os Percursos

Corrija apenas a camada confirmada: cabo ou porta do switch, reserva DHCP, sub-rede ou gateway, métrica da interface, regra da firewall, rota de retorno, registo DNS, rede permitida pela VPN ou relay multicast. Guarde a configuração anterior e agende um método de acesso local antes de reiniciar os serviços de rede.

Volte a testar o IP Ethernet, o nome de anfitrião, os dispositivos locais, o cliente VPN, a interface remota, a estabilidade do WebSocket e a descoberta pela mesma ordem. Reinicie o anfitrião uma vez e renove o estado de rede dos clientes para que rotas e DNS antigos não criem um sucesso temporário.

Um resultado aprovado mantém um acesso Ethernet fiável, conserva a rota VPN pretendida, evita percursos predefinidos duplicados e permite a descoberta apenas através de limites aprovados. Reverta as alterações se o percurso Wi-Fi funcional desaparecer ou se houver fugas de tráfego entre segmentos; proceda à escalada com provas da interface, da rota, da firewall e do fluxo de pacotes quando os pedidos chegam, mas as respostas continuam a sair incorretamente.