Re: Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox

Le vendredi 19 août 2022 à 09:39:14 UTC+2, Pascal Hambourg a écrit :

En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf
cas très particulier (configuration en pont-routeur avec ebtables) une
interface pontée ne devrait pas avoir d'adresse IP.

Ah ok, je ne savais pas. Dans mon cas, je me suis juste dis que je n'avais aucune
raison de mettre une IP à cette interface.

Si je pouvais trouver la référence/documentation qui fait mention de ce changement
de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit
documenté quelque part, ce qui est loin d'être sûr).

J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15
sans rien trouver de probant. Il me semblait que ce comportement était
bien antérieur.

Ok. Bon... on va dire que, avant ma migration quand j'étais sous Ubuntu 20.04, j'étais
sans doute dans une sorte de « corner case » avec mon bridge sans interface pontée
et que j'avais eu juste de la chance que ça marche ainsi. Désormais, je me rappellerai
qu'il faut impérativement au moins une interface pontée (même de type dummy sans
IP) pour que le bridge ait un "operational state" à UP (même si personnellement je
trouve ça dommage).

Autre chose : est-il nécessaire d'utiliser une interface bridge ?
Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble
qu'on pouvait spécifier une interface ethernet normale, et la VM était
pontée avec le réseau connecté à cette interface. Cependant je ne me
rappelle pas avoir vérifié si une interface bridge était créée
implicitement pour ce pontage ou si virtualbox se greffait directement
sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce
cas il devrait suffire d'associer la VM directement à une interface
dummy active.

Alors déjà, d'après mes recherches, tu ne verras jamais aucune interface créée par
Virtualbox (par exemple avec "ip l" ou "ip a", même en jouant avec les namespaces
etc.). C'est dommage pour le debug et pour comprendre ce qu'il se passe mais c'est
ainsi. De ce que j'ai compris, Virtualbox utilise son propre module kernel qui s'appelle
vboxnetflt et c'est lui qui gère le côté réseau. Alors peut-être qu'il crée des interfaces
virtuelle etc. mais on n'en sait rien et on ne voit rien avec les outils habituels comme ip.

Ensuite, tu as raison, je pourrais parfaitement « bridger » directement mes VM sur
mon interface eth0 qui est l'interface physique de mon desktop, celle qui me procure
de l'Internet. Et ça juste marche évidemment. Mais dans ce cas, les VM ont aussi
accès à Internet, ce que je ne souhaitais pas. En fait, sur mon desktop, j'ai quelques
services réseau qui écoutent sur br-virt et uniquement sur cette interface comme
un serveur DNS, un serveur DHCP (ça serait embêtant s'il écoutait sur eth0 !) et un
serveur HTTP proxy aussi. Comme ça, mes VM n'ont pas d'accès Internet mais
disposent tout de même d'un DHCP, d'un DNS et d'un proxy. Ça me permet de tester
des déploiements dans des conditions qui ressemblent à ce que j'ai en production.
D'où mon idée de départ d'utiliser un bridge br-virt. Ça m'a semblé une bonne façon
de faire par rapport à cette problématique, non ?

Enfin, tu me diras que, dans ce cas, pourquoi un bridge ? J'aurais parfaitement pu
utiliser directement une interface de type dummy (dummy-virt) avec l'IP 10.111.222.1/24,
sans m'embêter avec un bridge. Ça juste marche (je l'ai testé) et ça m'aurait évité
d'avoir le problème exposé dans ce fil de discussion. Mais je me dis que j'utilise
Virtualbox sur ma machine comme pour l'instant et peut-être qu'un jour j'aurai envie
d'utiliser autre chose, comme kvm par exemple. Et là, je pense que ce sera bel et bien
un bridge qu'il faudra sur mon desktop. Alors je m'étais dit autant utiliser un bridge, ça
m'évitera de changer la conf de mon desktop si je passe à kvm... Après, c'est peut-être
pas un bon argument, je ne sais pas...

Voilà, j'espère que ça répond à tes interrogations..