Depois de tentar uma configuração semelhante usando pimd , só posso concluir que :
- pacotes multicast normais (dados) são encaminhados, portanto, estão sujeitos a
filter/FORWARD, desde que o roteamento multicast esteja habilitado para esse fluxo. A entrada conntrackudp 17 29 src=10.4.4.5 dst=239.3.5.3 sport=10 dport=10 [UNREPLIED] src=239.3.5.3 dst=10.4.4.5 sport=10 dport=10 mark=0 use=1é um fluxo encaminhado e também aumentará os contadoresnat/PREROUTINGenat/POSTROUTINGpor (apenas) um: o pacote NOVO que acionou essa entrada de contração. - pacotes multicast link-locais (pacotes IGMP para 224.0.0. {1,22} e PIMv2 para 224.0.0.13) são interrompidos por
filter/INPUT. - Se o fluxo foi ativado antes, o roteador de multidifusão ativará o encaminhamento desse destino multicast específico por um tempo. Quando ocorrer um tempo limite configurado, durante o qual ele não recebeu nenhum relatório IGMP da LAN ou do PIMv2 da WAN devido ao firewall, ele considerará que não há mais cliente ou nenhum fluxo válido e deixará de encaminhar o fluxo multicast correspondente.
No final, você deve permitir que o roteador linux receba:
-
Pacotes IGMP vindos da LAN, para permitir que o roteador continue sabendo quais clientes de multicast estão ouvindo:
iptables -A INPUT -i br0 -p igmp -j ACCEPT -
Minha configuração específica está usando
pimde PIMv2, não sei se esse protocolo é sempre usado ou não, mas tive que permitir que o protocolo PIM funcionasse mantendo a política DROP, quando o IP de origem não foi apenas 192.0.2.1 (mas 10.4.4.5):iptables -A INPUT -s 192.0.2.1 -i eth0 -p pim -j ACCEPT -
Pode ser necessário permitir pacotes IGMP do roteador do ISP, mas minha configuração específica não os exige:
iptables -A INPUT -s 192.0.2.1 -i eth0 -p igmp -j ACCEPT
ATUALIZAÇÃO:
Observe que a política DROP da cadeia filter/INPUT ainda mostrará ocorrências: os pacotes IGMP e PIMv2 do roteador linux, sendo multicast, são retornados em loop ao sistema local quando enviados para fora e, portanto, são (inofensivamente) descartados, pois não são ativados por as regras acima. Depois de adicionar as regras correspondentes, eu acertei um comportamento estranho para o PIMv2 e no final tive que marcar os pacotes em filter/OUTPUT para permitir sua cópia em loopback em filter/INPUT . Enquanto isso eu também restringi a regra nat. No final, com as seguintes regras, o contador de políticas DROP de filter/INPUT sempre ficava em [0: 0] enquanto encaminhava o tráfego multicast:
# Generated by iptables-save v1.6.2 on Mon Aug 27 01:01:48 2018
*nat
:PREROUTING ACCEPT [1:56]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [1:56]
[0:0] -A POSTROUTING -s 192.168.0.0/24 -o eth0 -m comment --comment SNAT -j MASQUERADE
COMMIT
# Completed on Mon Aug 27 01:01:48 2018
# Generated by iptables-save v1.6.2 on Mon Aug 27 01:01:48 2018
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [1533311:325676232]
:OUTPUT ACCEPT [75:3724]
[0:0] -A INPUT -i lo -j ACCEPT
[1:56] -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[40:1800] -A INPUT -i br0 -p igmp -j ACCEPT
[14:774] -A INPUT -s 192.0.2.1/32 -i eth0 -p pim -j ACCEPT
[28:1288] -A INPUT -s 192.0.2.1/32 -i eth0 -p igmp -j ACCEPT
[17:932] -A INPUT -s 192.0.2.79/32 -i eth0 -p igmp -j ACCEPT
[28:1392] -A INPUT -m mark --mark 0x1 -j ACCEPT
[28:1392] -A OUTPUT -p pim -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Completed on Mon Aug 27 01:01:48 2018
Você pode simular um cliente de multidifusão e fazer o dump para o stdout com socat ( especifique o IP local se mais de uma interface):
socat -u UDP4-RECV:10,ip-add-membership=239.3.5.3:0.0.0.0 -