Porque é que o multicast não atravessa uma VPN sem um plano

Dois locais podem alcançar-se perfeitamente por unicast e mesmo assim comportar-se como se um deles não visse o anúncio de descoberta da impressora, o fluxo IPTV ou o batimento do cluster. Isto não é um túnel avariado; é a diferença entre um destino e um grupo. A entrega de multicast exige um modelo de pertença, estado de encaminhamento ao longo do caminho e uma interface disposta a transportar o tráfego, e nada disso vem de uma rota unicast. Ir do grupo da aplicação até um recetor que funcione é o caminho mais curto para uma resposta.

Comece pelo grupo e pela aplicação

Pergunte que endereço de grupo usa a aplicação e para que serve o tráfego. Um protocolo de descoberta que anuncia serviços, um fluxo de streaming e os pacotes de saudação de um protocolo de encaminhamento são três problemas diferentes com três respostas aceitáveis diferentes. O próprio endereço de grupo indica o âmbito: os endereços do bloco de controlo da rede local não se destinam a ser encaminhados para fora da ligação pelo encaminhamento comum, e as aplicações que os usam assumem normalmente um único domínio de difusão. Um fluxo de streaming num grupo de âmbito global é um desenho diferente de um protocolo de descoberta que espera que cada dispositivo ouça cada consulta, e só o segundo se preocupa com o tamanho do domínio de difusão.

Decida se o requisito é o serviço ou o mecanismo de descoberta, porque essas respostas diferem em custo numa ordem de grandeza. Uma pede um endereço que não muda; a outra pede um domínio de difusão estendido por uma ligação de área alargada com tudo o que daí decorre.

A descoberta local deve parar

O Multicast DNS descrito em RFC 6762 está desenhado em torno de uma única ligação: as consultas vão para um grupo fixo, as respostas são enviadas para o mesmo grupo, e o protocolo conta com cada participante a ouvir todos. Os encaminhadores não encaminham esse tráfego por omissão, e isso é uma decisão de desenho, não um descuido. A fronteira existe para que um dispositivo num edifício não possa anunciar-se casualmente noutro. Um túnel que parece corrigir a descoberta ao transportar o grupo para todo o lado removeu essa fronteira para todas as aplicações, não apenas para aquela que precisava de ajuda.

Existem repetidores e refletores, e são serviços reais com consequências reais: cada nome anunciado num local torna-se visível no outro, incluindo nomes de dispositivos que identificam pessoas ou equipamento. Se o requisito real é que um serviço concreto seja localizável, um registo de serviço publicado no DNS é normalmente a alteração mais pequena, e revela um nome em vez de um caudal deles.

Três coisas de que o multicast encaminhado precisa

O multicast encaminhado precisa de três coisas a trabalhar em conjunto: recetores que se juntam ao grupo, encaminhadores que mantêm estado de encaminhamento para ele e um túnel que trata os endereços de grupo como tráfego a transportar. Um túnel com uma política que só lista sub-redes unicast deixará cair o tráfego do grupo na fronteira da cifragem, e é por isso que o primeiro sintoma é muitas vezes silêncio em vez de um erro. Uma interface baseada em rotas, como um túnel GRE ou VTI, transporta o que a tabela de encaminhamento lhe enviar, o que torna o grupo alcançável assim que exista o estado de multicast.

A alcançabilidade da fonte é a segunda metade. Protocolos de encaminhamento multicast como o PIM constroem árvores de distribuição verificando que o caminho de regresso à fonte é o esperado, pelo que uma rota unicast que aponta para outro sítio quebra a árvore mesmo quando a pertença ao grupo está correta. Instalar uma rota para o recetor não faz nada por essa verificação, e é este o erro que produz um ping que funciona e um fluxo que falha. Verifique primeiro o caminho de retorno da fonte, depois acrescente a pertença e só então olhe para a aplicação.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

As duas primeiras linhas mostram a que se juntou o anfitrião e o que o núcleo encaminha, a terceira mostra a pertença da própria aplicação, e a última o caminho unicast que a verificação de caminho inverso vai usar. Lê-las em conjunto distingue uma aplicação que nunca se juntou de uma rede que nunca encaminhou.

Prove-o com uma fonte e um recetor

Antes de tocar numa configuração, confirme que a aplicação funciona num único segmento. Se falhar localmente, o encaminhamento multicast não é o problema e nenhuma alteração ao túnel ajudará. Depois repita com um recetor através do túnel e observe os pacotes dos dois lados da fronteira da cifragem.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Os pacotes visíveis dentro do túnel mas ausentes fora dele apontam para encapsulamento ou política; os pacotes visíveis dos dois lados sem progresso da aplicação apontam para a pertença do recetor ou para a ligação da aplicação. Mantenha as capturas curtas e filtradas, porque uma captura multicast ampla num segmento ocupado é sobretudo ruído.

Prefira um endereço de serviço quando só precisa do serviço

A descoberta existe para encontrar algo que se move. Um servidor com um nome estável não precisa de descoberta, e um endereço documentado em DNS privado responde à pergunta real do utilizador sem estender um domínio de difusão por uma ligação de área alargada. O mesmo raciocínio aplica-se a impressoras, eletrodomésticos e serviços web internos. Um nome no DNS é alcançável a partir de cada local que dele precise sem anunciar nada aos locais que não precisem, e continua a funcionar quando o dispositivo é substituído por outro com um endereço diferente.

Quando um protocolo exige mesmo multicast, limite-o ao grupo e aos locais que dele precisam, documente porquê e reveja a decisão quando a aplicação mudar. Estender a descoberta a todo o lado é fácil uma vez, e difícil de desfazer depois de um ano de dispositivos que dependem dela em silêncio.