我遇到了一个与Linux内核桥接有关的奇怪问题。 设置如下：
我想从OpenWRT路由器的用户空间进程通过vpn隧道（第2层隧道）向“Linux机器”发送数据包。 Linux机箱的VPN接口通过远程网络（DSL-Router）的DHCP-Server获取其IP。由于OpenWRT路由器不知道VPNs0（服务器站点）的地址（并且可以通过DHCP获得更改），因此使用magicIP（10.10.10.10）通过隧道联系Linux机器。 OpenWRT-Router的eth0后面还有一些特殊的设备，它们使用这个magicIP通过隧道联系linux盒。
为了归档这个，我添加了一个包含magicIP及其接口的静态路由，以及一个静态arp表条目，它指定了用于向这个magicIP发送数据包的接口。此外，这个神奇的IP实际上并没有设置在任何linux box的接口上。但是，在VPNs0（服务器站点）上接收的所有包含此magicIP的数据包都会被iptables重写为接口实际当前的ip-address。我知道这个设置有点hacky但它过去在OpenWRT路由器后面的设备上工作。现在我想在OpenWRT路由器本身使用相同的功能，但奇怪的事情发生了：
如果我对从magicWRT路由器到linux盒的magicIP进行ping操作，则根据路由表解析路由。之后ARP查找工作，因为它是静态提供的。因此，ping请求数据包正在进入具有正确目标mac地址（VPNs0的MAC）的br-lan接口。网桥的fdb表将此mac-address与正确的接口（VPN0）相关联，并通过隧道发送数据包。因为重播不起作用，但只要数据包通过就没问题。 但是，只要我将任何用户空间进程用于相同的magicIP，所有这些数据包都会在eth1上退出。根据fdb，这不会发生，因为相关的接口仍然是VPN0。 没有iptable或ebtable规则集可能会干扰桥接器切换的默认行为。
有人知道这可能来自哪里吗？
