在桥接模式下使用OpenVPN ARP应答从br0消失为tap0

我已经安装了一个Linux盒子（在esxi5上），它充当OpenVPN服务器。服务器配置为对客户端使用桥接，这实际上是有效的，只有一个例外。

如果客户端ping网络上不是服务器本身的计算机，则该计算机将无法工作。我排除了我所知道的一切（iptables等），运行tcpdump将其归结为以下几点：

我在tap0和br0上看到ARP请求
我看到ARP回应br0
我在tap0上看不到ARP答复

问题：为什么br0设备不将ARP答复转发给tap0设备？

— 分
source

好的-我走了一步。当我使用brctl showmacs观看网桥的mac表时，我在tap0端看到了我的vpn客户端的mac地址。如果我现在开始从VPN客户端ping通到子网，则mac地址将移至网桥端口，这当然会阻止子网的arp答复。当ping停止时，mac几乎立即切换回去。所以我不知道为什么mac地址切换到错误的切换端口-到目前为止，我所有的搜索都没有结果。

— 芬

如果它“移到”另一个端口，则可以确定该MAC地址在您的网络中存在多次，或者您看到了网络环路的影响（同一网桥的两个端口通过活动连接）路径）。两者都是需要解决的配置问题。

— the-wabbit 2014年

首先在客户端中使用静态ARP条目来隔离问题，如果ping之后可以正常运行，则可以继续进行ARP故障排除。如果它不起作用，那么您将面临比ARP更大的网络问题。

— 里卡多

由于我们无法知道任何关于您的网络看起来怎么样。远射；你有没有client-to-client在您的服务器的OpenVPN配置文件？如果您的服务器使用openvpn作为客户端连接到VPN网络，则该句子可能是正确的。PS。您正在使用哪种发行版？

— Michal Sokolowski

Answers:

没有更多的信息，我们正在猜测，但请尝试：

首先确保eth0和tap0都处于混杂模式。br0不应处于混杂模式。

接下来检查它是否具有arptables和任何可能会干扰的iptables规则。

当您已经收到arp答复时，您可能没有此答复，但还是请检查一下。

最后检查rp_filter设置，还要检查您可能设置的任何其他sysctl参数。

— gu田
source

...由于是ESXi，因此请确保在虚拟交换机上启用了混杂模式。

— 杰拉德·科姆斯

^ ^ ^ ^ 重要的是要在vSwitch上启用混杂模式，如果你正在运行ESXi。真。

— roaima

如果ESXi主机具有与网络的冗余连接，则由于Net.ReversePathFwdCheckPromisc的默认设置，可能会出现各种ARP问题。https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting中已描述了使用CARP的pfSense用户最早进行调试的过程。

在类似的环境中，我们在FreeBSD上设置了OpenVPN桥接，但同时也增加了VLAN的复杂性。在尚未将Net.ReversePathFwdCheckPromisc设置为1且存在到网络的多个上行链路的主机上，我们看到到Tap设备的入站流量出现大量数据包丢失（超过95％）。设置为1时，它可以正常工作。

— JG23
source