La réponse ARP disparaît de br0 à tap0 en utilisant OpenVPN en mode de pontage

J'ai installé une boîte Linux (sur un esxi5) qui agit comme un serveur OpenVPN. le serveur est configuré pour utiliser le pontage pour les clients, ce qui fonctionne essentiellement, à une exception près.

Si le client envoie un ping à une machine du réseau qui n'est pas le serveur lui-même, cela ne fonctionne pas. J'ai exclu tout ce que je sais (iptables, etc.) et l'exécution de tcpdump l'a réduit aux choses suivantes:

Je vois les requêtes ARP sur tap0 et br0
Je vois les réponses ARP sur br0
Je ne vois pas les réponses ARP sur tap0

Question: pourquoi le périphérique br0 ne transfère-t-il pas les réponses ARP au périphérique tap0?

— marais
source

ok - je suis allé plus loin. lorsque je regarde la table mac du pont à l'aide de showmacs brctl, je vois l'adresse mac de mon client vpn du côté tap0. si je commence maintenant à cingler du client vpn au sous-réseau, l'adresse mac se déplace vers le port de pont qui bloque bien sûr la réponse arp du sous-réseau. le mac revient presque immédiatement à l'arrêt du ping. donc ce que je ne sais pas, c'est pourquoi l'adresse mac passe au mauvais switchport - toutes mes recherches n'ont donné aucun résultat jusqu'à présent.

— fen

s'il "se déplace" vers un autre port, ce serait un indice certain que l'adresse MAC est présente plus d'une fois dans votre réseau ou que vous voyez les effets d'une boucle de réseau (deux ports du même pont connectés par un réseau actif). chemin). Les deux sont des problèmes de configuration qui doivent être corrigés.

— le-wabbit du

isolez le problème en utilisant une entrée ARP statique d'abord dans votre client, si les pings fonctionnent bien après cela, vous pouvez passer au dépannage d'ARP. Si cela ne fonctionne pas, vous avez un problème de réseau plus important que le simple ARP.

— Ricardo

Comme nous ne pouvons rien savoir à ce sujet à quoi ressemble votre réseau. Plan long; avez-vous client-to-clientdans le fichier de configuration openvpn de votre serveur? Si vos serveurs sont connectés au réseau VPN en utilisant openvpn comme client, la phrase pourrait être vraie. PS. Quel type de distribution utilisez-vous?

— Michal Sokolowski

Réponses:

Sans plus d'informations, nous devinons, mais essayons:

Assurez-vous d'abord que eth0 et tap0 sont en mode promiscuous. br0 ne doit pas être en mode promiscuité.

Vérifiez ensuite que vous avez des arptables et toutes les règles iptables qui pourraient interférer.

Comme vous avez déjà obtenir des réponses arp, votre probablement n'ont pas cela , mais vérifiez toute façon.

vérifiez enfin les paramètres de rp_filter , mais vérifiez également tous les paramètres sysctl supplémentaires que vous avez définis.

— higuita
source

... et comme c'est ESXi, assurez-vous que le mode promiscuous est activé sur le commutateur virtuel.

— Gerald Combs

^ ^ ^ ^ Il est essentiel d'activer le mode promiscuous sur le vSwitch si vous exécutez ESXi. Vraiment.

— roaima

Si votre hôte ESXi dispose de connexions redondantes au réseau, divers problèmes ARP peuvent apparaître en raison du paramètre par défaut de Net.ReversePathFwdCheckPromisc. Les utilisateurs de pfSense utilisant CARP ont été parmi les premiers à déboguer ceci, décrit ci-dessus sur https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting

Dans un environnement similaire, nous avons mis en place le pontage OpenVPN sur FreeBSD, mais aussi la complication supplémentaire des vlans. Sur un hôte où Net.ReversePathFwdCheckPromisc n'a pas été défini sur 1 et où plusieurs liaisons montantes vers le réseau existent, nous constatons une perte massive de paquets (95% +) sur le trafic entrant vers le périphérique de robinet. Cela fonctionne très bien lorsqu'il est réglé sur 1.

— JG23
source