![通过隧道(tun0)从 eth0 重复 mDNS/Bonjour 请求](https://linux22.com/image/1459757/%E9%80%9A%E8%BF%87%E9%9A%A7%E9%81%93%EF%BC%88tun0%EF%BC%89%E4%BB%8E%20eth0%20%E9%87%8D%E5%A4%8D%20mDNS%2FBonjour%20%E8%AF%B7%E6%B1%82.png)
首先,我对网络和 Unix/Ubuntu/Linux 发行版都很陌生。请注意,任何设置/代码可能看起来有点丑陋。
基本上,我的最终目标是成功地将 AirPlay Mirror 从我的 iPhone 在不同 WiFi 网络或 LTE 上传输到远程 Ubuntu 服务器。
TL;DR:使用 mdns-repeater/avahi-daemon 和 OpenVPN,我仍然无法将 mDNS 请求从 eth0 传递到 tun0。
首先,我知道我需要一个支持镜像的 Ubuntu/Linux/Unix 操作系统的 AirPlay 接收器(希望是开源的)。我找到了几个,大多数适用于 Mac OS/Windows,或者根本不支持镜像。经过一番搜索,我发现魔镜中的奴隶,一个可以运行和工作的开源 Linux AirPlay 服务器/接收器(基于我的调试,因为我无法物理访问我运行它的服务器)。
现在,我知道 AirPlay 只能通过 LAN 运行(当时不理解 Bonjour 为何只能在同一子网上工作),所以我研究了一些 VPN 选项。OpenVPN 似乎是最灵活、最容易设置的。为了加快速度并确保在设置 OpenVPN 时不会犯任何错误,我使用了来自这里。经过测试,运行完美,VPN 连接无 DNS 泄漏,所有流量均成功通过 VPN 路由。
我有 VPN,就好像我的设备现在在服务器的 LAN 上一样,并且 Magic Mirror(AirPlay 服务器)中的 Slave 已成功运行。所以它现在应该可以正常工作了,对吧?毫不奇怪,它没有工作,因为我不明白 AirPlay 服务器实际上会发出 mDNS/Bonjour 请求(或探测?真正的术语现在我记不清了……)。作为家庭常规用户,由于这些 mDNS 请求是零配置(零配置),这真是太棒了!但作为企业或商业用户,很难跨 VLAN 工作。
通过研究,我最终得出的结论是,我需要某种 mDNS 中继器/代理/桥接器类型的设置。我最终选择了 mDNS 中继器。我尝试使用两个程序。
avahi 守护进程
阿瓦希似乎是最常被谈论和记录最多的,所以我决定使用它。我编辑了配置文件以允许 配置位置 /etc/avahi/avahi-daemon.conf
[reflector]
enable-reflector=yes
和
[server]
allow-point-to-point=yes
乍一看,在调试模式下运行 Avahi Daemon(avahi-daemon --debug)似乎有效,但是一旦运行 Magic Mirror 中的 Slave(在 eth0 接口上运行,OpenVPN 在 tun0 接口上运行),它就会以某种方式看到 mDNS 数据包,但总是输出一堆这样的数据包:
Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.
强制 Avahi 仅使用 eth0 和 tun0,在进行许多其他更改和设置后总是输出这个。
为了验证这不仅仅是一个输出错误,我运行了
tcpdump -i eth0 udp port 5353
并且
tcpdump -i tun0 udp port 5353
(mDNS 请求通过的端口)eth0 成功接收来自过滤器的数据包,而 tun0 没有收到任何数据包。所以不是输出错误。我甚至在端口 7000(AirPlay 服务器监听镜像的端口)上尝试过
由于 Avahi 没有成功,我怀疑这可能只是因为它自 2011 年以来就没有更新过。
mdns-中继器
无需配置文件或设置,mdns-中继器是我选择的下一个选项。看起来它工作正常。使用以下命令运行 mdns-repeater
mdns-repeater eth0 tun0 -f
只需添加您想要重复请求的接口,并使用 -f 进行前台/调试。就是这样!我在 Magic Mirror 中运行了 Slave,mdns-repeater 成功检测并重复了请求(至少根据其日志)。但遗憾的是,运行与tcpdump
上面相同的命令,请求仍然没有通过隧道(tun0)。
现在,从我的调试结果来看,我只能得出这样的结论:要么是 iptables/防火墙的原因,要么是 OpenVPN 以某种方式过滤了端口或请求。在 OpenVPN 的配置中找不到与过滤相关的任何内容,于是我转向了 iptables 理论。但运行iptables -L
没有任何结果,实际上 iptables 中没有任何规则。
我对 iptables 了解甚少,不知道这是否是原因。为了我自己的调试,我添加了所有我能找到的与允许 mDNS / Bonjour / AirPlay 相关的不同 iptables 规则。似乎没有什么帮助。
非常感谢大家的帮助!我知道这篇文章很长,我不希望任何小问题被忽略。
TL;DR:使用 mdns-repeater/avahi-daemon 和 OpenVPN,我仍然无法将 mDNS 请求从 eth0 传递到 tun0。
答案1
dns-sd
您可以使用创建代理服务记录,而不必重复 mDNS 请求。如果您dns-sd -Z _raop._tcp
在具有 mDNS 记录的网络上运行,您应该会得到类似以下内容的信息:
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@Gavin\032speakers._raop._tcp
054D66DDCDBB@Gavin\032speakers._raop._tcp SRV 0 0 5000 boxen.local. ; Replace with unicast FQDN of target host
054D66DDCDBB@Gavin\032speakers._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"
您可以用它来制作代理记录,以将 AirPlay 客户端引导至您的服务器。对于我的示例连接,我将使用...
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"
...其中192.0.2.23
替换为您的 airplay 服务器的 IP 地址,其他所有内容均从您获取的内容中复制dns-sd -Z
。这样,AirPlay 客户端就应该能够看到您的服务器。
注意:dns-sd
我在这里使用的命令是 macOS 附带的。据我所知,它不适用于 Linux,但您可能可以使用 avahi 执行类似操作。
答案2
希望你一切安好,Gavin。你的回答与 TimeMachine 有关。如果你想通过 VPN 备份,你需要收集以下信息:代理广告如下所示。
$ host JustinsTimeCapsule2
JustinsTimeCapsule2 has address 192.168.123.232
$ dns-sd -Z _smb._tcp
Browsing for _smb._tcp
DATE: ---Thu 12 Aug 2021---
15:14:25.561 ...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.
_smb._tcp PTR JustinsTimeCapsule2._smb._tcp
JustinsTimeCapsule2._smb._tcp SRV 0 0 445 JustinsTimeCapsule2.local. ; Replace with unicast FQDN of target host
JustinsTimeCapsule2._smb._tcp TXT “”
...
并创建相关的代理广告在连接到 VPN 的主机上。
$ dns-sd -P 'JustinsTimeCapsule2' '_smb._tcp' 'local.' 445 JustinsTimeCapsule2.local 192.168.123.232
Registering Service JustinsTimeCapsule2._smb._tcp.local. host JustinsTimeCapsule2.local port 445
DATE: ---Thu 12 Aug 2021---
15:36:32.896 ...STARTING...
15:36:33.646 Got a reply for record JustinsTimeCapsule2.local: Name now registered and active
15:36:33.646 Got a reply for service JustinsTimeCapsule2._smb._tcp.local.: Name now registered and active
单击菜单栏中的“Time Machine”图标,然后选择“立即备份”。一切就绪。