我需要一些关于帖子主题的解释：我的情况在链接的图片中描述：
我有一个用于智能手机的 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