我现在遇到一个OpenVPN TUN模式下的网络难题，想请教各位技术大佬帮忙分析下。

先说说我的场景：我有一个手机APP需要和终端设备通信，已经用OpenVPN的TUN模式完成了所有配置，目前ping功能是正常的——手机能ping通终端设备，也能ping通拓扑里的其他设备。

但现在卡在了APP的设备发现功能上：APP是通过发送广播包来查找终端设备的，可广播包无法跨不同子网/网络传输。我本来打算在Mikrotik上配置dst-nat，把收到的广播包转换成指向终端设备IP的单播，类似Cisco的IP Helper功能，之前查资料说这是可行的，但测试过程中发现了一些奇怪的现象，让我有点摸不着头脑：

• 广播包无法跨隧道传输：从手机的角度看，tun0接口（隧道启动后生成的虚拟接口）应该是直连接口，我原本以为APP从这个接口发出的广播包，能像普通LAN里的ARP请求一样，到达隧道内其他设备的tun0接口，但实际用Wireshark在PC的tun0接口抓包，根本看不到手机APP发送的广播包。
• ARP响应的MAC地址异常：我做了个测试——清空PC的ARP表，然后ping手机，强制PC从tun0接口发送ARP请求来获取手机的tun0 MAC地址。抓包后发现：
  • PC发出的ARP请求：源MAC为00:ff:af:18:2b:e8，目的MAC为ff:ff:ff:ff:ff:ff
  • 收到的ARP回复：源MAC居然是00:ff:b0:18:2b:e8（这个地址和PC请求的源MAC只有第三个字节差了1，从af变成了b0），目的MAC是PC请求的源MAC00:ff:af:18:2b:e8（这部分是正常的）
    我换了其他设备、不同的MAC地址重复测试，发现回复的源MAC总是比请求的源MAC第三个字节加1。

基于这些现象，我有个猜测：任何设备从tun0接口发出的广播包，其实根本没有进入隧道网络，而是被本地的一个虚拟MAC地址“截获”了，这个虚拟地址会像网关一样回复。可能隧道内部的ARP这类数据是用专门的协议管理的，不是走普通LAN的广播机制？

如果我的猜测是对的，那不管是直接传输广播包，还是用类似IP Helper的方式转单播，是不是都走不通？另外我没法切换到TAP接口，因为IOS不支持TAP，而且Android的OpenVPN 3也开始不再支持TAP了，所以只能在TUN模式下寻找解决方案。

有没有大佬能帮忙分析下这个ARP异常的原因，或者给我指条路，让APP的广播发现包能成功到达终端设备？

备注：内容来源于stack exchange，提问作者Rick