mDNS dentro de uma VPN: por que nomes .local não são resolvidos

A impressora do escritório aparece em todos os aplicativos da sua mesa e desaparece na VPN, embora você consiga fazer ping no endereço que sabe que ela tem. Nada no túnel está quebrado: descoberta e acessibilidade são serviços separados, e apenas um deles atravessa um túnel roteado por padrão. As verificações abaixo separam os dois antes de você começar a adicionar rotas. Uma rota não corrige uma consulta que nunca saiu do enlace.

Verifique o que é resolvido hoje e o que só parece resolvido

Separe primeiro as duas perguntas: uma consulta unicast para um nome de host pergunta a um resolvedor, enquanto uma busca por _ipp._tcp pergunta ao enlace local. No Linux, avahi-browse -a mostra o que o DNS multicast consegue ver, e resolvectl query name.local mostra o que a pilha de resolvedores faz com esse nome. No macOS, dns-sd -B _ipp._tcp lista os serviços descobertos sem precisar de um endereço antes.

Se o endereço responde e o nome não, o roteamento funciona e a descoberta não. Um nome .local também pode ser respondido no próprio host via nss-mdns sem o avahi-browse instalado, então um getent ou ping bem-sucedido para esse nome não é prova de que a descoberta atravessou o túnel; o resultado da busca e o do resolvedor são evidências diferentes. Os aplicativos armazenam em cache o que descobriram, e por isso a falha costuma aparecer horas depois da conexão e não no momento da conexão. Feche e reabra o aplicativo e verifique se a entrada em cache contém um nome ou um endereço, porque um endereço continua funcionando muito depois de a descoberta parar.

Por que a consulta nunca atravessa o túnel

O DNS multicast envia consultas para 224.0.0.251, dentro do bloco de controle da rede local, na porta UDP 5353. Os roteadores não encaminham endereços desse bloco, então a consulta fica no enlace para onde foi enviada. Os emissores também definem o TTL de IP, ou o limite de saltos do IPv6, em 255 para que o receptor possa rejeitar um pacote que já atravessou um roteador; é assim que o protocolo detecta falsificação fora do enlace, não é assim que ele permanece local. A localidade vem do endereço de destino, não de um TTL de um único salto.

O tipo de túnel também importa. Uma interface no estilo tun transporta pacotes IP e nada mais, então nenhum grupo multicast sobrevive a ela. Uma ponte no estilo tap amplia o próprio domínio de difusão, e por isso alguns projetos antigos faziam ponte em vez de rotear, e herdaram todos os problemas que a ponte traz.

Uma exceção de LAN confiável não muda nada disso, porque decide qual tráfego pode usar o túnel em vez de ensinar o túnel a encaminhar multicast. O pacote continua sem um segmento compartilhado onde ser ouvido.

Escolha um projeto de nomenclatura que você consiga manter

Para os recursos da empresa, a resposta durável é um nome de host roteado servido pelo resolvedor que a VPN empurra, com DNS dividido para que nomes internos vão para servidores internos e todo o resto não. O Windows expõe isso como tabela de políticas de resolução de nomes, o macOS usa resolvedores com escopo por interface, e a maioria dos clientes tem um ajuste equivalente de push. O dispositivo mantém seu nome normal no DNS interno, e a descoberta deixa de fazer parte do caminho.

Um proxy de descoberta ou um refletor mDNS pode preencher essa lacuna, e é um projeto real com seu próprio host, sua própria exposição e seus próprios requisitos de cliente. Ele não aparece porque você adicionou uma rota. Nunca encaminhe consultas .local para um resolvedor público: o domínio é reservado para uso multicast local pelo RFC 6762, e enviá-lo para fora produz falhas lentas e divulgação desnecessária de dados.

Verifique o serviço, não o nome

Um nome em uma lista de busca prova a etapa de descoberta, não que o serviço responda. Abra a fila de impressão ou a interface web e conclua uma operação real, e repita-a após uma reconexão.

A descoberta armazena nomes em cache de forma agressiva, então uma entrada obsoleta pode parecer um sucesso. Se aparecer um certificado ou uma solicitação de autenticação, essa é a camada seguinte e um problema separado. Anote qual mecanismo você alterou, resolvedor ou descoberta, para que a próxima pessoa não precise reabrir a questão inteira.