App não pode receber pacotes multicast no CentOS 7

Question

Eu tenho uma máquina do CentOS 7.2 que é uma convidada do VMware. Estou assinando um grupo de multicast e vendo todo o multicast que eu esperava, mas meu aplicativo não está vendo o conteúdo do fluxo. strace mostra que está aguardando uma chamada de sistema select (). O que estou esquecendo?

Veja o que eu fiz:

• Iniciou um remetente multicast em um host remoto.
• Construiu um convidado do CentOS 7.2 em um host VMware.
• Eu paro e desabilito o firewalld e yum erase filewalld no convidado. iptables -L mostra:

-

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

• eu corro: socat UDP4-RECVFROM:65000,ip-add-membership=239.31.82.10:10.0.54.210,fork STDOUT
• não vejo saída do comando.
• netstat -gn mostra que está inscrito no grupo multicast.
• o selinux está desativado, em /etc/selinux/config eu vejo: SELINUX=disabled . Sim, reiniciei desde essa configuração. Também vejo: SELinux status: disabled de sestatus
• tcpdump -n -nn -i eth0 host 239.31.82.10 mostra pacotes atingindo a interface daquele IP, destinado à porta UDP 65000.
• Outro host inscrito no mesmo grupo de multidifusão vê os dados.
• Eu construo outro guest da VM, desta vez usando o CentOS 6.4, e funciona bem. Eu vejo a saída regular do meu remetente multicast.
• Eu construo outro guest da VM, novamente usando o CentOS 7.2, e funciona bem. Desta vez eu uso uma instalação mínima, no entanto.

Meu problema parece como o firewall está bloqueando os pacotes, mas como mostrado, não há firewall habilitado.

A diferença significativa entre meu host que não funciona e meu host de trabalho é que o host que não trabalha tem duas interfaces configuradas nele. Mas, novamente, eu estou mostrando isso como inscrito no grupo multicast e estou mostrando pacotes atingindo a interface. Além disso, encerrei a segunda interface, mas isso não ajudou.

Obrigado.

    

Answer 1

AGH! Palavras famosas,

The one significant difference between my not-working host and my working host is ...

... por aí estão dragões!

AGH! Suposições famosas,

...But...

... pois aí está a raiz de toda confusão!

O problema é a filtragem de caminho reverso de rede do Linux. O problema é que os pacotes estão chegando em uma interface e a tabela de roteamento vê que o endereço do host de envio deve passar pela outra interface (na qual está o roteador padrão). Portanto, o kernel estava descartando os pacotes e não os enviando para o meu aplicativo.

Os relatórios IGMP foram enviados porque, bem, eu disse a socat qual interface eu deveria usar. E os roteadores e switches montaram o multicast corretamente para ir exatamente onde eu mandei. Em última análise, foi o kernel que não foi feliz.

O conserto barato e desprezível é usar sysctl para alterar net.ipv4.conf.all.rp_filter de 1 para 0 , mas isso pode causar consequências imprevistas se você não for cuidadoso (pacotes fora de ordem, recebendo pacotes que você não usa) t quer, pacotes chegando na interface errada). É melhor garantir que a tabela de roteamento reflita a realidade do que você está tentando fazer. Portanto, a outra correção é definir /etc/sysconfig/network-scripts/route-iface para que haja uma rota de origem ou de rede específica para o IP do emissor de multicast nessa determinada iface (ou seja, eth1 ou o que você tem).