Porque é que o mesmo nome mDNS é resolvido para dispositivos diferentes entre VLANs domésticas?
O mesmo nome mDNS pode resolver para dispositivos diferentes entre VLANs quando cada segmento vê um conjunto diferente de anúncios locais ou refletidos.
Numa rede doméstica ZimaSpace, os serviços NAS, o Home Assistant, as impressoras, as colunas e os contentores podem anunciar nomes .local em VLANs separadas, de confiança e IoT. O mDNS foi concebido para funcionar na rede local, pelo que um refletor ou repetidor determina quais os anúncios que atravessam o router. Nomes de anfitrião duplicados, interfaces assimétricas do refletor e caches desatualizadas podem fazer com que dois clientes recebam respostas diferentes para o mesmo nome.
Confirme se o mDNS está a ser refletido entre VLANs encaminhadas
Compare a mesma consulta em cada VLAN e verifique em que interfaces o refletor está à escuta.
Um artigo especializado sobre redes domésticas OpenWrt em o mDNS precisa de um refletor entre redes encaminhadas ajuda a isolar este cenário, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Se uma VLAN nunca vê os anúncios do outro segmento, corrija o âmbito do refletor antes de investigar as caches DNS.
Verifique quais as VLANs autorizadas a enviar tráfego de descoberta
A política da firewall deve permitir o percurso de descoberta esperado sem abrir acesso unicast não relacionado.
Um registo especializado de uma implementação de rede doméstica em o mDNS e o DNS precisam de regras inter-VLAN definidas deliberadamente ajuda a isolar este cenário, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Mantenha as regras de descoberta de serviços separadas do encaminhamento amplo entre VLANs, para que a resolução de problemas não destrua a segmentação.
Verifique se o refletor está a funcionar nas interfaces corretas
Um refletor ligado a apenas uma VLAN pode criar uma visibilidade parcial que parece uma resolução de nomes inconsistente.
Um guia especializado sobre Homebridge e Avahi em o Avahi pode refletir registos entre interfaces VLAN selecionadas ajuda a isolar este cenário, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Liste as interfaces do refletor e remova da reflexão os segmentos WAN ou de convidados adicionados acidentalmente.
Separe o mDNS de outros protocolos de descoberta
O Chromecast e alguns dispositivos domésticos combinam o mDNS com outras portas multicast ou unicast.
Um guia especializado sobre redes do Home Assistant em a descoberta entre VLANs pode exigir mais do que mDNS ajuda a isolar este cenário, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Se o nome for resolvido, mas o serviço continuar a falhar, teste as portas de dados efetivamente utilizadas pela aplicação em vez de adicionar mais repetidores mDNS.
Verifique a rede do contentor do servidor doméstico
O Home Assistant ou outro serviço de descoberta executado dentro do Docker pode não ver as mesmas interfaces multicast que o anfitrião.
Um artigo especializado sobre Kubernetes em laboratórios domésticos em o Home Assistant em contentores precisa de uma acessibilidade multicast inter-VLAN definida deliberadamente ajuda a isolar este cenário, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Compare uma consulta mDNS ao nível do anfitrião com a consulta dentro do espaço de nomes do contentor antes de editar as regras do router.
Teste a existência de nomes duplicados e respostas em cache
Dois dispositivos que anunciem o mesmo nome de anfitrião .local podem ficar visíveis em VLANs diferentes, dependendo da reflexão e do momento em que as respostas são guardadas em cache.
Um artigo especializado sobre redes de laboratórios domésticos em o mDNS entre VLANs depende de uma reflexão controlada ajuda a isolar este cenário, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Renomeie os duplicados, limpe apenas a cache do cliente de teste e repita as capturas em ambas as VLANs. O resultado correto é um único proprietário estável para cada nome necessário.
Volte a testar o percurso exato até ao servidor doméstico
Depois de alterar uma variável, repita o mesmo fluxo de trabalho NAS ou autoalojado a partir do mesmo cliente, em vez de mudar para um teste diferente que possa utilizar outro percurso.
O guia ZimaSpace relacionado em o percurso de rede adjacente do servidor doméstico ajuda a manter a verificação final associada ao mesmo ambiente autoalojado.
A correção só está concluída quando o sintoma original continua resolvido após voltar a ligar, reiniciar o serviço e realizar uma segunda transferência ou pedido controlado.
Perguntas frequentes
Porque é que duas VLANs podem resolver o mesmo nome .local de forma diferente?
Podem ouvir anúncios locais diferentes ou receber registos refletidos diferentes e guardá-los em cache em momentos distintos.
Ativar um refletor mDNS permite acesso completo da IoT à minha LAN de confiança?
Não, por si só. A descoberta e o tráfego unicast dos serviços devem ser controlados por regras de firewall separadas.
Todas as VLANs devem participar na reflexão mDNS?
Não. Reflita apenas os segmentos que necessitam de descoberta partilhada, para reduzir o ruído e a visibilidade não intencional.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
