Como adaptar uma configuração do Home Assistant para utilizadores remotos e locais

Adapte o Home Assistant para utilizadores remotos e locais mantendo o caminho de controlo local direto e adicionando depois um caminho remoto autenticado separado, que não se torne uma dependência para quem já está em casa. Os utilizadores locais devem continuar a conseguir aceder ao Home Assistant quando a Internet ou o fornecedor de acesso remoto estiver indisponível; os utilizadores remotos devem obter acesso encriptado sem expor serviços desnecessários.

Conceba isto como dois caminhos de ligação que utilizam o mesmo modelo de identidade e autorização do Home Assistant. Comece por garantir um DNS local funcional e um endereço LAN estável, escolha a extremidade remota e, em seguida, teste o comportamento de telemóveis, navegadores, painéis, notificações e utilizadores domésticos quando passam de redes Wi-Fi para redes móveis.

Mantenha o caminho local independente da extremidade remota

Para o controlo local, os clientes devem resolver o Home Assistant para um endereço acessível pela LAN e permanecer dentro da rede doméstica. Isto evita enviar um pedido próximo para a Internet e fazê-lo regressar através de um túnel ou proxy público. Também significa que o controlo básico pode continuar a funcionar durante uma falha do ISP, desde que a LAN, o DNS, o anfitrião do Home Assistant e os protocolos dos dispositivos locais se mantenham funcionais.

Se for utilizado o mesmo nome de anfitrião público dentro e fora de casa, o DNS dividido pode devolver um endereço privado na LAN e um endereço público/de túnel noutros locais. Um guia claro sobre como o DNS dividido mantém o tráfego local na LAN mostra como isto evita o encaminhamento hairpin e preserva um caminho local direto, mantendo simultaneamente um único nome fácil de memorizar.

Escolha uma extremidade remota adequada à casa

O acesso remoto pode ser fornecido por um serviço gerido, uma rede VPN/sobreposta, um proxy inverso ou um túnel. A escolha certa depende de quem precisa de acesso. Uma VPN pode ser excelente para um administrador técnico, mas tornar-se um obstáculo para os restantes membros da família se todos os telemóveis tiverem de manter uma ligação adicional. Uma solução gerida ou baseada em túnel pode ser mais simples para utilizadores não técnicos, mas acrescenta uma dependência externa que não deve ser necessária para o controlo local.

Uma análise recente sobre as diferenças entre métodos de acesso remoto relativamente a CGNAT, segurança e utilização familiar é útil porque avalia VPNs, túneis e exposição direta tendo em conta o CGNAT, a segurança e a facilidade de utilização pela família, em vez de tratar todo o acesso remoto como o mesmo problema. Evite o simples reencaminhamento de portas públicas quando puder utilizar uma extremidade autenticada e encriptada.

Utilize DNS e certificados para tornar previsível a mudança entre clientes

As falhas no acesso remoto/local surgem frequentemente quando um telemóvel muda de rede. O nome de anfitrião público pode ser resolvido incorretamente na LAN, um certificado pode não corresponder a um nome apenas interno, um resolvedor DNS privado pode ser ignorado ou uma VPN pode continuar a utilizar uma rota destinada apenas a ligações fora de casa. Documente qual o resolvedor e o nome de anfitrião que cada cliente deve utilizar em ambos os estados.

Em configurações mais complexas, nomes de anfitrião locais e remotos separados podem tornar os caminhos explícitos. Um guia detalhado da comunidade do Home Assistant sobre um design remoto e local com dois caminhos demonstra este padrão: DNS local direto para clientes da LAN, um nome de anfitrião remoto protegido de forma independente e testes do comportamento em segundo plano dos dispositivos móveis.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separe as permissões dos utilizadores da localização da rede

Não trate “dentro de casa” como equivalente a “administrador”. Atribua a cada membro da casa o seu próprio utilizador do Home Assistant e reserve os direitos administrativos para quem realmente precisa de alterar integrações, utilizadores ou definições do sistema. O acesso remoto deve autenticar o caminho de ligação, e o Home Assistant deve continuar a autenticar a pessoa.

Teste também o comportamento específico de cada dispositivo. Um tablet de parede pode precisar apenas de acesso à LAN. Um telemóvel familiar pode precisar de painéis e notificações remotos. Um portátil de administrador pode precisar de uma VPN para o Home Assistant e para outros serviços privados. Manter estas funções explícitas evita conceder um mecanismo amplo de acesso remoto a todos os dispositivos apenas por ter sido conveniente durante a configuração.

Valide quatro cenários de falha antes de considerar a configuração concluída

Teste a rede Wi-Fi local com a Internet disponível, a rede Wi-Fi local com a Internet desligada, o acesso móvel/remoto e uma falha da extremidade remota enquanto a rede local continua funcional. Em cada caso, verifique o início de sessão, um painel, um comando, o resultado de uma automação e qualquer caminho de notificações ou multimédia relevante. Isto revela se uma experiência “local” continua dependente de DNS público ou de um proxy externo.

Compare a latência nos caminhos LAN e remotos, em vez de esperar que tenham um comportamento idêntico. O artigo da ZimaSpace sobre por que motivo a latência do Home Assistant difere entre caminhos LAN e remotos explica por que razão o DNS, o encaminhamento, a encriptação, os proxies e a qualidade da rede do cliente acrescentam diferentes atrasos fora de casa.

Um bom design do Home Assistant para acesso remoto e local não obriga todos os utilizadores a utilizar o mesmo caminho de rede. Mantém o controlo local na rede local, adiciona o acesso remoto como uma capacidade segura e separada e utiliza DNS, certificados, contas de utilizador e testes de falhas consistentes, para que a mudança de rede não se transforme num problema de resolução.