A descoberta de Chromecast e DLNA nunca atravessa uma VPN encaminhada

O botão de transmissão não lista nada, o VLC DLNA fica vazio e a máquina do outro lado responde ao ping sem se queixar. Essa combinação não é um problema de largura de banda nem um mistério de firewall. A descoberta nestes protocolos é uma troca de grupo no segmento local, e um túnel encaminhado não transporta tráfego endereçado a grupo. A sessão que tenta iniciar nunca é oferecida.

A acessibilidade está bem. Falta a descoberta.

O mito: o túnel precisa de uma definição ou de mais capacidade

As sugestões habituais são ativar o tráfego entre pares, aumentar a MTU ou mudar o tipo de dispositivo do túnel. Nenhuma delas acrescenta um domínio de difusão. O multicast é entregue pelos comutadores e pela pilha de rede local, e uma interface TUN ponto a ponto não tem qualquer endereço de grupo para inundar.

Mudar definições pode tornar a falha mais ruidosa. Não consegue fazer aparecer um anúncio onde o protocolo nunca enviou um.

O que é, na realidade, a troca de descoberta

Três padrões cobrem quase tudo o que vai encontrar. O mDNS envia para 224.0.0.251 em UDP 5353, o SSDP envia para 239.255.255.250 em UDP 1900, e as antigas listas de navegação SMB iam para o endereço de difusão da sub-rede. Cada uma é endereçada a um grupo e não a um anfitrião, e cada uma espera um ouvinte no mesmo segmento. Um recetor do outro lado de um túnel encaminhado não está nesse segmento, por isso nada chega.

Mesmo um anúncio reencaminhado transporta uma carga útil: normalmente o endereço LAN e a porta do emissor, que o espetador remoto tem depois de conseguir alcançar.

Leia uma captura antes de mudar o túnel

Capture na interface do túnel enquanto a aplicação faz a análise. Uma captura vazia significa que o anúncio nunca atravessou a fronteira, e nenhum ajuste do túnel muda isso. Os pacotes que aparecem enquanto a aplicação continua a não mostrar nada costumam significar que o endereço anunciado não é alcançável a partir do espetador, o que é um problema de encaminhamento disfarçado de descoberta.

Dois minutos de captura substituem uma hora de conjeturas sobre portas: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Três soluções, a mais barata primeiro

Aponte o cliente diretamente para o endereço do serviço. Para DLNA, SMB e servidores de multimédia simples isto salta a descoberta por completo e prova que o caminho da carga útil funciona, o que o torna o melhor primeiro teste e também uma solução alternativa utilizável. O Chromecast é a exceção, porque o recetor espera ser encontrado e não endereçado.

Reencaminhe o protocolo no gateway. Um refletor mDNS repete os anúncios entre o túnel e a LAN, e o Avahi inclui uma secção de refletor que aceita uma lista explícita de interfaces. Mantenha o reencaminhamento estreito e confirme que o endereço anunciado é alcançável dos dois lados, senão a resposta continua a apontar para uma sub-rede para a qual o espetador não consegue encaminhar.

Faça uma ponte em vez de encaminhar. Um segmento TAP em que o servidor liga o dispositivo tap à LAN coloca as duas pontas no mesmo domínio de difusão, por isso os anúncios passam sem alterações. É também a opção mais cara, porque uma só sub-rede significa um só domínio de falha e cada serviço multicast da LAN passa a chegar a cada par.

O que não ajuda, por mais que seja sugerido

Passar de dev tun para dev tap sem uma ponte deixa um dispositivo TAP que continua encaminhado, por isso o comportamento não muda. client-to-client permite unicast entre pares e não inunda as difusões. Reencaminhar uma porta de descoberta para um só anfitrião não entrega tráfego endereçado a grupo. Um servidor de multimédia ligado a um só endereço continua a responder nesse endereço até a sua própria configuração incluir a interface VPN.

Teste um pedido unicast direto e depois um pedido anunciado. Se o primeiro funcionar e o segundo não, o túnel está são e a descoberta é o problema todo.