Je cherche à créer deux machines virtuelles qui sont toutes deux connectées au même réseau privé. J'utilise Linux avec qemu-kvm 1.0.
Mon plan d'attaque a été le suivant:
brctl addbr bridge
ifconfig bridge up
tunctl -t tap1
tunctl -t tap2
ifconfig tap1 up
ifconfig tap2 up
brctl addif bridge tap1
brctl addif bridge tap2
qemu-kvm -net nic,macaddr=52:54:00:11:22:33 -net tap,ifname=tap1 disk1.img
qemu-kvm -net nic,macaddr=52:54:00:44:55:66 -net tap,ifname=tap2 disk2.img
Une fois démarrées, je donne à la première machine l'adresse IP 192.168.100.5, et la deuxième 192.168.100.10.
À ce stade, lorsque j'essaie de faire un ping d'une VM à l'autre, il n'y a aucune réponse au ping. Cependant, en utilisant Wireshark, je vois que des requêtes ARP sont envoyées et répondent, et j'ai vérifié que les caches ARP contiennent les informations sur les autres VM. Pourtant, aucune réponse au ping n'est générée (comme vu via Wireshark).
Ensuite, j'ai essayé de donner à la bridge une adresse IP de 192.168.100.1. Après cela, le ping entre les VM fonctionne, mais il y a toujours un problème: maintenant, toutes les requêtes semblent provenir de la bridge elle-même. Par exemple, si je me connecte d'une VM au serveur FTP de l'autre, en exécutant netstat sur la VM avec le serveur FTP, on voit que 192.168.100.1 est la source. Les connexions fonctionnent comme avec NAT, mais comme avec NAT, l'adresse source n'est pas celle de la machine d'origine. J'ai essayé cela avec net.ipv4.ip_forward activé et désactivé, et masquerading (iptables -t nat -A POSTROUTING -j MASQUERADE) activé et désactivé, avec les mêmes résultats.
Ce que je veux vraiment, c'est que mes VM se comportent comme si elles étaient branchées sur un commutateur: cela devrait être transparent. Je suis plus préoccupé par le fait que l'adresse source ressemble à celle de la bridge que par le fait que la bridge nécessite une adresse IP. Ce dernier est assez ennuyeux, mais le premier est un obstacle pour moi.
0 votes
Il s'avère que ceci est un problème sur Debian, mais pas sur Arch (je n'ai pas encore testé d'autres distributions). Je n'ai pas encore identifié pourquoi cela se produit sur Debian, mais cela permet une solution de contournement pour le moment.
0 votes
J'ai enfin trouvé une solution. Les variables sysctl suivantes doivent être définies :
net.bridge.bridge-nf-call-arptables = 0, net.bridge.bridge-nf-call-ip6tables = 0, net.bridge.bridge-nf-call-iptables = 0
Vous pouvez trouver des explications ici.