Repetindo solicitações mDNS / Bonjour de eth0 através de 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 é conseguir 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 in the Magic Mirror , um servidor Linux AirPlay de código aberto / receiver que executa e funciona (com base na minha depuração, pois não tenho acesso físico ao servidor em que o executei).

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 . 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

Avahi parecia ser o mais falado e 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 e aqui .

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 somente 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-repetidor

Sem arquivos de configuração ou configuração necessária, mdns-repeater é a próxima opção que eu tirei. 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.

    
por Pyrology 02.08.2015 / 01:28

1 resposta

2

Você poderia, em vez de repetir as solicitações do mDNS, usar dns-sd para criar um registro de serviço de proxy. Se você executar dns-sd -Z _raop._tcp na rede com o registro mDNS disponível, deverá obter algo assim:

Browsing for _raop._tcp
DATE: ---Mon 21 May 2018---
 1:29:38.528  ...STARTING...

; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp                                 PTR     @

; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.


_raop._tcp                                      PTR     054D66DDCDBB@Gavin2speakers._raop._tcp
054D66DDCDBB@Gavin2speakers._raop._tcp       SRV     0 0 5000 boxen.local. ; Replace with unicast FQDN of target host
054D66DDCDBB@Gavin2speakers._raop._tcp       TXT     "pw=false" "txtvers=1" "vn=3" "sr=44100" "ss=16" "ch=2" "cn=0,1" "et=0,1" "ek=1" "sm=false" "tp=UDP"

Você pode usar isso para criar um registro de proxy para direcionar os clientes do AirPlay ao seu servidor. Para o meu exemplo de conexão, eu usaria ...

dns-sd -P '054D66DDCDBB@Gavin speakers' '_raop._tcp' 'local.' 'boxen.local' '192.0.2.23' "pw=false" "txtvers=1" "vn=3" "sr=44100" "ss=16" "ch=2" "cn=0,1" "et=0,1" "ek=1" "sm=false" "tp=UDP"

... onde 192.0.2.23 é substituído pelo endereço IP do seu servidor airplay e tudo o mais é copiado do que você obtém de dns-sd -Z . Com isso, os clientes do AirPlay devem poder ver seu servidor.

Nota: o comando dns-sd que estou usando aqui vem com o macOS. Tanto quanto eu sei, não está disponível para o linux, mas você provavelmente poderia fazer algo semelhante com o avahi.

    
por 21.05.2018 / 10:37