Qui peut m'expliquer pourquoi bridge-utils améliore le réseau d'une vm "vmware" ?

Hello à tous,

Contexte
Je virtualise un windows 7 pour faire des démonstrations de visioconférence.
Dans l’idéal, la visio demande des flux en temps réel pour le transfert audio et vidéo.
Sinon, l’encapsulation est ok au prix d’un surcroît de latence.

Je virtualise avec Vmware Workstation.
Par défaut, le mode pont est géré par l’application et c’est le paramétrage de ma machine virtuelle. Dans ce cas, la vidéo de la caméra ne s’affiche pas.

Si je rajoute bridge-utils et que je bind eth0 au pont émulé, alors la vidéo de la caméra s’affiche dans la machine virtuelle.

Dans les 2 cas, les communications ne se font pas en udp mais sont encapsulées en tcp/443.

Je vous précise d’abord les détails techniques et après je pose les questions.

Détails techniques
Accès internet = Freebox revolution.
Paramétrages Freebox = affectation dhcp pour les pc à la maison avec dns “opendns” (pour un filtrage léger et éviter que les ch’tits nenfants tombent par inadvertance sur des sites pas joli-jolis).

PC hôte = debian jessie “backports” + lxde + vmware workstation + bridge-utils + “dns google”.
Modèle PC hôte = Dell Latitude e6530.
Paramétrages PC hôtes = Pilotes propriétaires installés (nécessaire pour le chipset WiFi + remplacement de “nouveau” par "nvidia-legacy-304xx). Wicd installé pour gérer les accès WiFi. Modification de /etc/network/interfaces comme suit :
auto lo
iface lo inet loopback

##allow-hotplug eth0
##iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_waitport 0
bridge_fd 0

PC virtualisé = windows 7 pro sp1 32bit.
Paramétrages PC virtualisé = “vmware tools” installés + adaptateur réseau en mode “bridge” + dns “google”.

Solution de visioconférence testée avec le PC virtualisé = Vidyo.
Caractéristiques Vidyo = tcp/443 pour l’accès au portail d’authentification ; tcp/17990 et 17992 pour l’authentification de compte ; 6 à 8 trames “temps réel” par conférence dans la plage dynamique udp/50000 à 65535 pour les flux audio, vidéo et de contenu.
Si la plage udp/50000 à 65535 n’est pas autorisée, ou pour fonctionner avec des proxy, encapsulation automatique des trames “temps réel” en tcp/443.

Les questions
Pourrait-on m’expliquer pourquoi la visioconférence en environnement virtuel fonctionne lorsque bridge-utils est utilisé, svp ?

Pourquoi les trames udp/50000-65535 à priori ne passent pas et que devrais-je faire pour que les communications ne soient pas encapsulées ?

Merci d’avoir pris le temps de lire jusque là et bonne journée à tous.

Ma réponse est peut-être hors-sujet, mais j’ai la flemme de lire ton très long message.
En fait, quand tu utilises le bridge de VMWare, c’est l’hyperviseur (ou superviseur, je ne sais plus) de VMWare qui s’en occupe, il doit donc simuler des interfaces réseau pour le bridge et ce n’est pas son boulot (il n’est probablement pas correctement optimisé pour).
Quand utilises bridge-utils, tu crées un pont réseau directement géré par le noyau, ce qui doit beaucoup aider car c’est beaucoup mieux optimisé.

Merci Almtesh pour ta réponse.

Vmware utilise un réseau virtuel “vmnet0” de type “bridge” qui fait de l’auto-pontage avec eth0, wlan0 et br0 (br0 étant bindé sur eth0 avec bridge-utils).

Quelle est alors la différence pour Vmware entre utiliser eth0 et br0 ?
Je ne vois pas du tout ce que cela change. J’ai pensé à une correspondance sur le modèle OSI mais je ne sais absolument pas ce qui différencie eth0 et br0.