O Home Assistant abre localmente, mas falha remotamente após uma alteração no router

Se o Home Assistant continuar a abrir na rede local depois de mudar de router, o Core e o caminho básico da LAN estarão provavelmente a funcionar. A falha estará mais provavelmente na atribuição de endereços do novo router, na regra NAT, no IP público, no registo DNS, na rota da VPN ou do túnel, ou no caminho do proxy inverso.

Não reinstale o Home Assistant para corrigir uma falha exclusivamente remota. Primeiro, confirme o endereço local e, em seguida, avance para o exterior, um limite de cada vez, até encontrar o primeiro ponto em que a nova rede já não corresponde ao design de acesso remoto anterior.

Confirme que o novo router não alterou o endereço LAN do Home Assistant

O novo router pode utilizar uma sub-rede diferente ou atribuir ao Home Assistant uma concessão DHCP diferente. Assim, uma regra de reencaminhamento de portas copiada do router antigo pode apontar para um endereço que já não pertence ao anfitrião do Home Assistant.

Encontre o endereço atual na lista de clientes do novo router ou nas definições de rede do Home Assistant e, em seguida, abra esse endereço exato a partir de um dispositivo na LAN. Se o acesso local funcionar, crie uma reserva DHCP se depender de um destino interno fixo para o NAT ou para o encaminhamento do proxy inverso.

O guia da ZimaSpace sobre separar alterações do IP da LAN de alterações do IP público e do DNS é o primeiro limite indicado depois de substituir um router.

Reconstrua o caminho de entrada remota para o novo router

Se utilizar o reencaminhamento direto de portas, recrie a regra no novo router e confirme que o destino é o endereço LAN atual do Home Assistant e a porta de escuta correta. Se utilizar uma VPN ou um túnel de saída, confirme que o conector está online e que o novo router não está a bloquear o caminho de saída ou de retorno de que necessita.

A documentação de acesso remoto do Home Assistant distingue Home Assistant Cloud, VPN, proxy inverso e caminhos de reencaminhamento de portas. A substituição de um router afeta estes métodos de forma diferente, por isso resolva o problema de acordo com o método que realmente utiliza, em vez de copiar uma regra NAT antiga para uma configuração baseada em VPN.

Teste através de dados móveis ou de outra rede verdadeiramente externa. Testar o nome de anfitrião público a partir da mesma LAN pode gerar confusão devido ao NAT loopback ou ao comportamento de DNS dividido.

Verifique se o IP público ou a situação de CGNAT foram alterados

Uma nova instalação de router coincide frequentemente com uma nova concessão WAN, um reinício do modem ou uma alteração no aprovisionamento do ISP. Se o IPv4 público tiver mudado e o DNS dinâmico não tiver sido atualizado, o nome de anfitrião pode continuar a apontar para a ligação antiga.

Compare o endereço WAN apresentado pelo router com o endereço público visível a partir da Internet. Se o router receber um endereço privado ou partilhado da operadora, em vez de um IPv4 público, o reencaminhamento direto de portas poderá deixar de funcionar, porque o CGNAT do ISP está a montante.

Não continue a editar o Home Assistant quando o novo router não controla o limite NAT público. Em vez disso, utilize o Home Assistant Cloud, uma VPN de malha, um túnel inverso ou solicite um IP público ao ISP.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique separadamente o DNS e o URL externo do Home Assistant

Resolva o nome de anfitrião exato utilizado remotamente e confirme que devolve o endereço público ou do túnel pretendido. Em seguida, teste diretamente o destino, quando possível. O sucesso do DNS não prova que o proxy ou a porta estejam corretos, e uma porta funcional não prova que o nome de anfitrião seja resolvido corretamente.

A aplicação Companion pode utilizar caminhos internos e externos diferentes. A documentação atual de rede abrange URLs internos, URLs externos, DNS, IPv4/IPv6 e o comportamento do proxy inverso. Uma alteração de router pode revelar definições obsoletas que permaneciam invisíveis enquanto a rede antiga coincidia, por acaso, com essas definições.

Se a aplicação falhar, mas um navegador através de dados móveis funcionar, compare o URL e o perfil de rede utilizados pela aplicação antes de alterar o servidor.

Volte a verificar a confiança no proxy inverso apenas se o caminho do proxy tiver mudado

Um novo router também pode alterar as sub-redes do Docker, os endereços do proxy ou a máquina que termina o TLS. Se os pedidos passarem agora por um proxy inverso diferente, o Home Assistant poderá rejeitar cabeçalhos encaminhados até que o novo proxy seja considerado fidedigno.

A integração HTTP requer uma configuração de proxy fidedigno para proxies inversos tradicionais que enviam cabeçalhos X-Forwarded. Não amplie a rede fidedigna para toda a LAN apenas para fazer desaparecer o erro; considere fidedigna a origem real do proxy.

Neste ponto, a falha deverá pertencer a uma única camada: destino LAN incorreto, rota NAT/túnel em falta, endereço público alterado, CGNAT, DNS obsoleto ou confiança no proxy.

FAQ

Preciso de um novo certificado TLS apenas porque mudei de router?

Normalmente, não. Uma alteração de router não invalida, por si só, um certificado para o mesmo nome de anfitrião. Os problemas com o certificado surgem quando o nome de anfitrião, o caminho do desafio, o proxy, o DNS ou a terminação TLS foram alterados.

Por que motivo o URL remoto funciona com dados móveis, mas falha na rede Wi-Fi de casa?

Isso aponta para um problema de encaminhamento ou DNS exclusivamente interno, como NAT hairpin ou DNS dividido, e não para uma falha geral do acesso remoto. Teste separadamente a resposta DNS interna e o caminho do proxy.