![隧道网络上的 OpenVPN 广播](https://linux22.com/image/788341/%E9%9A%A7%E9%81%93%E7%BD%91%E7%BB%9C%E4%B8%8A%E7%9A%84%20OpenVPN%20%E5%B9%BF%E6%92%AD.png)
我需要一些关于帖子主题的解释:我的情况在链接的图片中描述:
我有一个用于智能手机的 APP,它可以与终端设备通信,我已完成所有配置(使用带 TUN 配置的 OpenVPN)并且一切正常,我可以从智能手机 ping 通终端设备和图中显示的其他设备。现在的问题是:APP 使用发现数据包来查找终端设备,但这行不通,因为广播数据包无法在不同网络/子网之间传输。我想尝试配置 dst-nat,将从 Mikrotik 收到的广播转换为指向终端设备 IP 的单播,如 Cisco IP Helper,我了解到这应该是可行的,但是进行一些测试时我发现了一个奇怪的行为:从智能手机的角度来看,接口 tun0(隧道运行时上升)应该是一个直接连接的接口,因此我预计由 APP 生成并离开此接口的广播数据包应该到达其他设备隧道的所有 tun0 接口,就像普通 LAN 一样,像 ARP 请求数据包一样,显然这些数据包无法通过隧道网络转发。在 PC 上运行 WireShare 并从 PC tun0 接口捕获,我看不到智能手机 APP 生成的广播数据包。为什么???
我尝试进行以下测试:删除 PC 的 arp 表并对智能手机执行 ping 操作,强制 PC 从 tun0 发出新的 arp 请求以查找手机 tun0 mac 地址,所有这些都使用 wireshark 捕获。我发现 PC 执行 ARP 请求,源 MAC 为 00:ff:af:18:2b:e8 (tun0),目标 MAC 为 ff:ff:ff:ff:ff:ff,ARP 回复通过源 MAC 地址到达,其值为 00:ff:b0:18:2b:e8 (!!!) 和目标 MAC 00:ff:af:18:2b:e8(请求的原始 PC 源,这是正确的)。实际上,这个 MAC 回复源地址似乎与 PC 源 MAC 请求地址的值相同,但第三个字节增加了 1,我也尝试使用其他设备和不同的 MAC 地址进行此测试,MAC 回复的第三个字节始终增加了 1。
因此,我怀疑从任何设备接口离开 tun0 的广播实际上并没有通过隧道网络,而是被本地虚拟 MAC 地址关闭,该地址像网关一样回复。可能,像 ARP ecc 这样的数据管理是在隧道内部使用专用协议进行管理的。如果这是真的,那么就没有办法将广播带到终端设备,也不能使用 IP Helper 方式。主要问题是我无法使用 TAP 接口,因为 IOS 不支持它,而且带有 OpenVPN 3 的 Android 也正在朝这个方向发展。
谢谢!R