Repetindo solicitações mDNS / Bonjour de eth0 a um túnel (tun0)

3

Para começar, sou bastante novo em redes e distribuições Unix / Ubuntu / Linux. Apenas um aviso, para qualquer configuração / código pode parecer um pouco feio.

Basicamente, meu objetivo final é o AirPlay Mirror para um servidor Ubuntu remoto do meu iPhone em uma rede wifi diferente ou em LTE.

TL; DR: Com mdns-repeater / avahi-daemon e OpenVPN, ainda não consigo passar as requisições mDNS de eth0 para tun0.

Para começar, eu sabia que precisava de um receptor AirPlay para sistemas operacionais baseados em Ubuntu / Linux / Unix que suportassem espelhamento (e esperançosamente código aberto). Eu encontrei um casal, a maioria para Mac OS / Windows, ou não suportava o espelhamento. Depois de um pouco mais de pesquisa, encontrei Slave no Magic Mirror [Link 1 abaixo] , um servidor / receptor Linux AirPlay de código aberto que funciona e funciona (com base em minha depuração, pois não tenho acesso físico para o servidor que eu corri em).

Agora, eu sabia que o AirPlay só passava pela LAN (na época, não entendendo como o Bonjour funciona apenas na mesma sub-rede), então procurei algumas opções de VPN. O OpenVPN parecia ser o mais flexível e fácil de configurar. Para acelerar as coisas e garantir que não cometas erros ao configurar o OpenVPN, usei um script pré-fabricado de aqui [Link 2 abaixo] . Testado e trabalhado de forma impecável, a VPN se conecta sem vazamentos de DNS e todas as rotas de tráfego com êxito por meio da VPN.

Eu tenho minha VPN para agir como se meu dispositivo estivesse na LAN do meu servidor agora, e eu tenho o Slave no Magic Mirror (servidor AirPlay) sendo executado com sucesso. Então deveria funcionar agora, certo? Não surpreendentemente, isso não aconteceu, como eu não entendi o servidor AirPlay realmente envia solicitações mDNS / Bonjour (ou sondas? O termo real está escorregando minha mente agora ..). Como uma casa, usuário convencional, uma vez que essas solicitações mDNS são zeroconf (configuração zero), isso é incrível! Mas, como usuário corporativo ou comercial, é difícil trabalhar com VLANs.

Por meio de pesquisa, descobri o resultado final de que preciso de algum tipo de configuração de tipo repetidor / proxy / ponte do mDNS. Acabei com o repetidor mDNS. Havia dois programas que tentei usar.

Avahi-Daemon [Link 3 abaixo] Avahi parecia ser o mais falado e mais documentado, então decidi usar isso. Eu editei o arquivo de configuração para permitir Local de configuração /etc/avahi/avahi-daemon.conf

[reflector]
enable-reflector=yes

e

[server]
allow-point-to-point=yes

Como explicado aqui [Link 4 abaixo] e aqui [Link 5 abaixo] .

A execução do Avahi Daemon no modo de depuração (avahi-daemon --debug) pareceu funcionar à primeira vista, mas assim que o Slave no Magic Mirror (rodando na interface eth0, OpenVPN rodando na interface tun0) é executado, ele vê o pacotes mDNS de alguma forma, mas sempre produz um monte destes:

Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.

Forçando o Avahi a usar apenas eth0 e tun0, em cima de muitas outras mudanças e configurações, sempre será produzido.

Para verificar, não foi apenas um erro de saída que eu executei

tcpdump -i eth0 udp port 5353 e %código% (porta onde as solicitações do mDNS passam) O eth0 recebe pacotes com êxito do filtro enquanto tun0 não recebe nenhum. Então não é um erro de saída. Eu até tentei na porta 7000 (porta que o servidor AirPlay escuta no espelhamento)

Sem sucesso com o Avahi, suspeitei que talvez fosse porque não foi atualizado desde 2011.

mdns-repeater [link 6 abaixo] Sem arquivos de configuração ou configuração necessária, esta é a próxima opção que eu tomei. E parece que isso está funcionando corretamente. Execute mdns-repetidor com

mdns-repeater eth0 tun0 -f

Basta adicionar as interfaces que você deseja que as solicitações sejam repetidas e -f para o primeiro plano / depuração. É isso aí! Eu corri Slave no Espelho Mágico e mdns-repetidor detectou com sucesso e repetiu os pedidos (de acordo com o seu 'logs, pelo menos). Mas, infelizmente, executando os mesmos comandos tcpdump -i tun0 udp port 5353 como visto acima, os pedidos ainda não estão passando pelo túnel (tun0).

Agora, da minha depuração, só posso concluir que é a causa do iptables / firewall ou do OpenVPN que filtram as portas ou solicitações de alguma forma. Não encontrando nada na configuração relacionada à filtragem no OpenVPN, mudei para a minha teoria do iptables. Mas executar tcpdump não traz nada, literalmente não há regras no iptables.

Sabendo pouco sobre o iptables, não sei se esta é a causa. Para minha própria depuração, eu adicionei todas as regras diferentes do iptables que eu encontrei relacionadas a qualquer coisa que permitisse mDNS / Bonjour / AirPlay. Nada parece ser de ajuda.

Toda e qualquer ajuda é apreciada! Eu sei que esta foi uma leitura longa, eu não queria que nenhum pequeno problema aparecesse.

TL; DR: Com mdns-repeater / avahi-daemon e OpenVPN, ainda não consigo passar as requisições mDNS de eth0 para tun0.

Todos os links para fontes aqui: link Desculpas, não tenho reputação suficiente para mais de dois links no momento.

    
por Pyrology 02.08.2015 / 01:07

1 resposta

1

Não sei as respostas, mas para um início, as interfaces tun não suportam broadcast. Se você usar o tap eles fazem. Tho parece que o tap é usado para bridging na documentação OVPN você pode usá-los em configurações que usam tun. Eles se comportarão quase identicamente, mas indicarão BROADCAST como opção suportada quando você configurá-los.

    
por 19.06.2017 / 21:24