Die ARP-Antwort verschwindet mit OpenVPN im Bridging-Modus von br0 nach tap0

9

Ich habe eine Linux-Box (auf einem esxi5) eingerichtet, die als OpenVPN-Server fungiert. Der Server ist so konfiguriert, dass für die Clients Bridging verwendet wird, was mit einer Ausnahme im Wesentlichen funktioniert.

Wenn der Client einen Computer im Netzwerk anpingt, der nicht der Server selbst ist, funktioniert er nicht. Ich habe alles, was ich weiß (iptables usw.), ausgeschlossen und tcpdump ausgeführt, um Folgendes zu erreichen:

  • Ich sehe ARP-Anfragen auf tap0 und br0
  • Ich sehe die ARP-Antworten auf br0
  • Ich sehe die ARP-Antworten NICHT auf tap0

Frage: Warum leitet das br0-Gerät keine ARP-Antworten an das tap0-Gerät weiter?

vmware-esxi openvpn bridge arp tap fen
quelle
1
ok - ich bin noch einen Schritt weiter gegangen. Wenn ich mir die Mac-Tabelle der Bridge mit brctl showmacs ansehe, sehe ich die Mac-Adresse meines VPN-Clients auf der tap0-Seite. Wenn ich jetzt anfange, vom VPN-Client zum Subnetz zu pingen, wechselt die Mac-Adresse zum Over-Bridge-Port, der natürlich die Arp-Antwort des Subnetzes blockiert. Der Mac schaltet fast sofort zurück, wenn der Ping stoppt. Was ich also nicht weiß, ist, warum die Mac-Adresse auf den falschen Switchport umschaltet - alle meine Suchanfragen haben bisher zu keinen Ergebnissen geführt.
Fen
Wenn es auf einen anderen Port "verschoben" wird, ist dies ein eindeutiger Hinweis darauf, dass die MAC-Adresse entweder mehr als einmal in Ihrem Netzwerk vorhanden ist oder Sie die Auswirkungen einer Netzwerkschleife sehen (zwei Ports derselben Bridge, die durch einen aktiven verbunden sind Pfad). Beides sind Konfigurationsprobleme, die behoben werden müssen.
The-Wabbit
1
Isolieren Sie das Problem, indem Sie zuerst einen statischen ARP-Eintrag in Ihrem Client verwenden. Wenn Pings danach gut funktionieren, können Sie mit der Fehlerbehebung bei ARP fortfahren. Wenn es nicht funktioniert, haben Sie ein größeres Netzwerkproblem als nur ARP.
Ricardo
Da wir nichts darüber wissen können , wie Ihr Netzwerk aussieht. Langer Schuss; Haben Sie client-to-clientin der OpenVPN-Konfigurationsdatei Ihres Servers? Wenn Ihre Server mit openvpn als Client mit dem VPN-Netzwerk verbunden sind, kann der Satz wahr sein. PS. Welche Art von Distribution benutzt du?
Michal Sokolowski

Antworten:

1

Ohne weitere Informationen raten wir, aber lassen Sie uns versuchen:

Stellen Sie zunächst sicher, dass sich sowohl eth0 als auch tap0 im Promiscuous-Modus befinden. br0 sollte sich nicht im Promiscuous-Modus befinden.

Als nächstes überprüfen Sie, ob Sie Arptables und alle Iptables-Regeln haben, die möglicherweise stören.

Wie bereits Sie arp Antworten bekommen, Sie haben wahrscheinlich nicht diese , aber es trotzdem überprüfen.

Überprüfen Sie abschließend die Einstellungen für rp_filter , aber auch alle zusätzlichen sysctl-Parameter, die Sie möglicherweise festgelegt haben.

Higuita
quelle
1
... und da es sich um ESXi handelt, stellen Sie sicher, dass der Promiscuous-Modus auf dem virtuellen Switch aktiviert ist.
Gerald Combs
^ ^ ^ ^ Es ist wichtig , den Promiscuous - Modus auf dem vSwitch zu aktivieren , wenn Sie ESXi laufen. Ja wirklich.
Roaima
1

Wenn Ihr ESXi-Host über redundante Verbindungen zum Netzwerk verfügt, können aufgrund der Standardeinstellung von Net.ReversePathFwdCheckPromisc verschiedene ARP-Probleme auftreten. pfSense-Benutzer, die CARP verwenden, gehörten zu den frühesten, die dies unter https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting beschrieben haben

In einer ähnlichen Umgebung haben wir OpenVPN-Bridging auf FreeBSD eingerichtet, aber auch die zusätzliche Komplikation von vlans. Auf einem Host, auf dem Net.ReversePathFwdCheckPromisc nicht auf 1 gesetzt wurde und auf dem mehrere Uplinks zum Netzwerk vorhanden sind, tritt ein massiver Paketverlust (95% +) beim eingehenden Datenverkehr zum Tap-Gerät auf. Es funktioniert gut, wenn auf 1 gesetzt.

JG23
quelle