5 votes

Création d'un réseau privé pour deux machines virtuelles

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.

2voto

mgorven Points 29736

J'ai déjà vu iptables interférer avec le trafic de ponts auparavant (même si cela ne devrait pas à ma connaissance). Vous ne voulez certainement pas de règles liées à NAT, mais je pense que la chaîne FORWARD doit accepter les paquets. Je suggérerais de tester cela sans règles iptables et une politique ACCEPT par défaut sur la chaîne FORWARD.

Quelques autres choses à vérifier :

  • Est-ce que brctl show vérifie que tap1 et tap2 sont dans bridge ?
  • Est-ce que brctl showmacs bridge montre les adresses MAC des deux VMs ?

0 votes

J'ai vérifié que j'ai une politique d'acceptation par défaut sur FORWARD, donc malheureusement ce n'est pas le problème. Les périphériques de type "tap" sont attachés et les machines virtuelles sont affichées avec showmacs (mais également les périphériques de type "tap", si cela compte). J'ai également eu l'occasion d'essayer quelque chose de similaire sur une machine avec Open vSwitch, et j'ai obtenu le résultat souhaité (l'adresse IP source semble correcte), donc peut-être devrais-je passer à cela.

1voto

NotMySolve Points 1

Définissez vos interfaces tap en mode promiscuous.

ifconfig tap1 promisc up
ifconfig tap2 promisc up

0 votes

Merci, mais malheureusement, il n'y a eu aucun changement après cela: la communication était toujours en panne et les adresses IP étaient toujours mêlées.

1voto

atat Points 1

L'ARP nécessite également un routage pour fonctionner.

Un problème courant est que vous avez à la fois une adresse IP assignée aux deux interfaces dans le même sous-réseau, sur le noyau du système hôte. Si vous le faites, les réponses ARP ne fonctionneront pas correctement car une seule interface recevra les réponses. Assurez-vous d'avoir un itinéraire propre et unique vers le sous-réseau.

Dans l'exemple ci-dessus, si les interfaces tap1 et tap2 avaient toutes deux une adresse IP dans le noyau Linux de l'hôte - dans le même sous-réseau (192.168.100.0/24), les réponses ARP ne fonctionneraient pas. Si les machines virtuelles ne nécessitaient pas de connectivité avec l'hôte, aucune des deux n'aurait besoin d'une adresse IP dans le noyau de l'hôte.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X