[technique] Virtualisation du routage IPv4 pour les VM

[Laurent GUERBY]

Bonjour,

Pour mettre en place des VM pour nos adhérents sur le Dell R310 des
étudiants de l'N7 au neocenter de Balma nous avons du choisir une
méthode de routage et d'adressage IPv4.

Dans un mode classique les VM de la machine auraient été placées dans un
subnet sur un brdige par exemple /29 donc 8 IPv4 avec la premiere comme
subnet, la derniere comme broadcast et une pour le hote/gateway soit 3
IP utilisées en infrastructure pour 5 utiles pour les VM.

Cette méthode consomme donc pas mal d'IPv4 et mets les VM sur un meme
bridge donc avec tous les soucis L2 (rogue DHCP/RA/spoofing) potentiels
entre les utilisateurs. Elle ne permet pas non plus de deplacer
facilement une des VM pour la mettre sur une autre machine.

La solution choisie pour la premiere VM a été différente et s'inspire de
ce qui est fait en IPv6 ou nous utilisons des IPv6 link-local pour
router.

L'idée est d'utiliser une IP /32 "virtuelle" pour la gateway, ici nous
avons pris une IP publuique 91.224.148.0/32 qui est la premiere IPv4
attribuée a tetaneutral.net mais qui n'est pas vraiment utilisable sur
l'internet de toutes façons. Sur l'hote :

ip addr add 91.224.148.0/32 dev lo
ip route add 91.224.148.xxx dev tapvm

Sur la VM :

ip addr add 91.224.148.xxx/32 dev eth0
ip route add 91.224.148.0/32 dev eth0
ip route add default via 91.224.148.0

Lorsque la VM veut envoyer un paquet son noyau va generer une requete
ARP who-has pour trouver la MAC de la gateway 91.224.148.0. Cette
requete arrive sur tapvm sur l'hote et comme par défaut sous
Linux /proc/sys/net/ipv4/conf/all/arp_filter est a zero meme si l'IP en
question est sur la loopback "lo" qui est distincte de tapvm, le noyau
hote va quand meme repondre positiviement avec la MAC de tapvm. La VM a
alors tout ce qu'il faut pour communiquer avec le reste de l'internet.

Les avantages sont multiples :
- consommation optimale d'IPv4, une VM = une IP, une seule IP est
utilisée en infrastructure sur tout l'AS
- pas de probleme de L2 car la VM est la seule sur son interface avec le
host
- on peut deplacer la VM dans notre reseau sans que l'adherent change
son parametrage

Pour le moment a part un fichier /etc/network/interfaces peu
habituel sur la VM pas d'inconvénient constaté.

La mise en place sous Libvirt et /etc/network/interfaces a été faite par
Mehdi avec des hooks :

http://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Libvirt

Merci a tous ceux qui ont contribué a la mise en place de cette
solution,

Sincèrement,

Laurent