☰

Configure a rota multicast em um salto intermediário

tag-icon • tag-icon routing openvpn multicast
Configure a rota multicast em um salto intermediário

Eu tenho um host com dois contêineres Docker (com NET_ADMINcapacidade):

  • backendcom uma interface eth0( 172.16.7.3)
  • openvpn-servercom interfaces eth0( 172.16.7.2) e tun0( 10.8.0.1), executando um servidor OpenVPN (modo tun)

Existe um cliente OpenVPN em outra máquina openvpn-clientcom interface tun0( 10.8.0.2). A VPN está funcionando.

Configuração adicional de rota:

  • backendtem rotas 10.8.0.0/24 via 172.16.7.2e 224.0.0.0/4 via eth0.
  • openvpn-servertem rotas 10.8.0.0/24 dev tun0e 224.0.0.0/4 dev tun0.

backendpode executar ping com sucesso openvpn-client(roteado através de openvpn-server): ping 10.8.0.2funciona perfeitamente.

Observações:

Quando executo ping -t3 239.1.2.3on openvpn-server, eles passam pelo túnel VPN e posso ver os pacotes ICMP chegando openvpn-client(com tcpdump -i tun0 net 224.0.0.0/4on openvpn-client).

Além disso, quando executo ping -t3 239.1.2.3on backend, eles saem pelo host eth0e entram em on openvpn-server's eth0. Eu posso vê-los openvpn-serverusando tcpdump -i eth0 net 224.0.0.0/4.

Problema:

Eu gostaria de poder continuar executando ping -t3 239.1.2.3e backendencaminhando os pings para openvpn-client, como se 10.8.0.2tivesse sido feito um ping. (O objetivo final é fazer multicast de pacotes UDP backendpara todos os clientes VPN.)

Minha tentativa:

smcroute -d -n -j eth0 239.1.2.3 -a eth0 172.16.7.3 239.1.2.3 tun0

Achei que isso configuraria a rota multicast, mas na verdade não faz nada. Não consigo ver os pacotes ICMP de saída nos openvpn-serverarquivos tun0. -- O que está errado?

Também tentei configurar pimddois pares dos três hosts e também todos os três. Como resultado, eu poderia fazer um iperfbenchmark (como sugeridoaqui) entre backende openvpn-server, e também entre openvpn-servere openvpn-client, mas não entre backende openvpn-client. Parece que o encaminhamento/roteamento através do salto intermediário de alguma forma não funciona. (Eu configurei o TTL para 5, então esse não deveria ser o problema.)

Terei prazer em fornecer mais detalhes, se necessário (como ip route listresultados), mas não queria sobrecarregar a questão desnecessariamente.

Responder1

O problema é que eu não me certifiquei de openvpn-clientingressar no grupo multicast, então o roteador do meio ( openvpn-server) não sabia que deveria enviar tráfego multicast para lá.

A seguinte configuração é suficiente:

  • Em backend, configure a rota 224.0.0.0/4 via 172.16.7.2- isso garante que o tráfego para o intervalo de IP multicast seja enviado para openvpn-server(você pode especificar um intervalo mais estreito)
  • Instale e pimdcomeceopenvpn-server

  • Certifique-se de que openvpn-clientanuncia que deseja ingressar no grupo multicast.Para esse fim, é necessário um daemon IGMP como esse scmroute. Isso funciona apenas em duas etapas:

    1. smcroute -d--inicia o daemon
    2. smcroute -j tun0 239.1.2.3- para entrar no grupo

    Observe que não é possível executar ambos em um comando ( smcroute -d -j tun0 ...).

Dessa forma, tudo funciona conforme o esperado.

Observação:Se você iniciar os daemons pimdou smcrouteantes da configuração do OpenVPN tun0, as coisas não funcionarão. É melhor iniciá-los usando route-upo gancho do OpenVPN.

informação relacionada