Mai 222011
 

Tout ce qui suit concerne l’utilisation de Xen4 sur une base Debian 6.0 (Squeeze) sur architecture amd64 avec les serveurs dédiés « dedibox » proposés par online.net
Il est (très) probable que cela soit spécifique à cette distribution / ce datacenter.

Attention : Online.net tire à vue sur les gros lourdauds qui font n’importe quoi avec leur config réseau (et ils ont raison de le faire… )
aussi, avant d’appliquer bêtement ce tuto, tachez de comprendre un petit peu ce que vous faites.
un petit ip --help et man ip ne seront pas trop pour éviter les boulettes.
Vigilence extrème et plus que jamais : RTFM !

Remarque importante : Ce qui suit concerne les PVM (ParaVirtualized Machine). Pour les HVM avec Qemu, voir un autre (futur) post.

Il y a 2 problèmes importants :

  • Premièrement le respect de la mac imposée par le datacenter pour configurer l’interface de la machine virtuelle
  • Deuxièmement, le routage un poil bizare utilisé pour les IP failover.

Concernant le mode bridge : il n’y a pas trop de souci.
Vous devez demander l’allocation d’une adresse MAC au datacenter, puis il suffit de spécifier l’adresse mac dans le fichier de configuration de la VM.
exemple :
vif = [ 'ip=88.190.XXX.XXX,mac=00:16:3e:00:XX:XX' ]

Sur votre machine hôte, il vous faudra aussi avoir dans /etc/xen/xend-config.sxp les lignes suivantes :

(network-script network-bridge)
(vif-script vif-bridge)

Dès que vous aurez fini l’installation de votre PVM (je suppose que vous maitrisez déjà debootstrap) il faut impérativement ajouter quelques lignes dans les bons fichiers pour tenir compte du routage un peu particulier que pratique online.net

Il est probable (voir certain) que l’ip failover soit dans un VLAN différent de votre ip principale sur ce serveur. Or, comme il ne s’agit que d’une redirection, l’adresse du routeur reste celle qui sert à votre machine Hote, laquelle n’est ‘logiquement’ pas joignable depuis le reseau de l’ip-failover.

Disons par exemple que votre VM a une ip en 88.190.AAA.BBB mais que votre machine hote est en 88.190.CCC.DDD
La paserelle de la machine hote est logiquement 88.190.CCC.1.
La paserelle de votre VM devrait etre 88.190.AAA.1 si AAA était un VLAN « normal », mais dans ce cas il s’agit bien de 88.190.CCC.1.
Problème si vous specifiez dans le /etc/network/interfaces de votre VM

auto eth0
iface eth0 inet static
address 88.190.CCC.DDD
netmask 255.255.255.0
gateway 88.190.AAA.1

Ca ne peut pas marcher car le reseau AAA de la gateway n’est pas joignable.

Pour corriger ce problème, j’ai vu maintes fois sur le net la configuration suivante

auto eth0
iface eth0 inet static
address 88.190.CCC.DDD
netmask 255.255.0.0
gateway 88.190.AAA.1

Ça fonctionne mais avec l’inconvénient majeur que vous vous fermez l’accès à toutes les machines qui sont dans 88.190.0.0/16 mais pas dans 88.192.AAA.0/24.
Bref, c’est de la bidouille.

La configuration qui me parait la plus juste est la suivante :

  • Dire que la machine est seule dans son vlan et DOIT communiquer avec le routeur pour toutes les autres.
  • Spécifier une exception pour que l’ip du routeur soit déclarée joignable directement par eth0
  • Spécifier le routeur comme route par défaut (c’est à dire pour tout le trafic d’après le netmask )


auto eth0
iface eth0 inet static
address 88.190.CCC.DDD
netmask 255.255.255.255
post-up ip route add 88.190.AAA.1 dev eth0
post-up ip route add default via 88.190.AAA.1

Ça fonctionne à un détail près : Si vous avez des échanges entre plusieurs de vos VM (au hasard, un serveur web et un serveur SQL), ces infos passeront systématiquement par le routeur plutôt que de s’échanger directement entre les box. Outre la fait que cela peut impacter négativement les performances, le vrai problème est que le trafic va sortir de votre machine hôte, et pourra donc potentiellement être sniffé par tout équipement situé entre votre box et le routeur, ce qui vous contraindra à crypter les échanges.
Vous pouvez contourner cette limitation en ajoutant des routes spécifiques pour ces machines là
ajoutez simplement des lignes post-up dans votre fichier /etc/network/interfaces

  One Response to “Routage et bridging pour PVM Xen sur Dedibox.”

  1. Concernant les routes spécifiques pour certaines machines, vous devrez évidemment faire l’ajout des deux cotés, car même si elle est appelée directement, l’autre machine répondra en suivant sa propre table de routage.

Sorry, the comment form is closed at this time.