Routage et bridging pour HVM Xen sur Dedibox.

 Trucs et astuces techniques  Commentaires fermés sur Routage et bridging pour HVM Xen sur Dedibox.
Mai 222011
 

SVP lisez le post Routage et bridging pour PVM Xen sur Dedibox. avant de lire celui-ci.

ATTENTION !
lisez tout avant de manipuler, il y a moyen de perdre la main sur la machine hôte assez facilement.

Les HVM diffèrent un peu des machines PVM. En particulier dans la déclaration du bridging.
Pour faire le bridging, les PVM utilisent une interface vif qui est bridgée sur peth0.
Dans le cas des HVM, une interface vif est bien crée mais elle me semble inutilisée. Une autre interface tap est également crée et est elle aussi bridgée sur peth0
cependant à la diférence des vif qui sont créées avec une mac fe:ff:ff:ff:ff:ff les interfaces tap sont créées avec des mac randomisées.
Cela serait sans la moindre importance si le noyau Linux n’avait l’idée stupide d’affecter à un bridge la mac la plus basse de toutes les interfaces connectées au bridge en question.
Donc, si la mac randomisée pour votre tap est plus petite que celle de votre eth0 (la mac de mon eth0 commence par BC pas de chance) vous perdrez la main sur votre machine hôte (en plus, vous diffusez un mac illégale, alors soyez heureux si online.net ne vous blackliste pas pour tentative de spoofing. )

La solution : Modifier le script de création de l’interface virtuelle pour mettre la mac de la tap à fe:ff:ff:ff:ff:ff ( fe au début pour éviter le ff partout qui est l’adresse de broadcast. Personnellement, j’aurais plutôt mis le fe à la fin mais comme j’ai vu partout comme ça, je suppose qu’il y a une bonne raison…. ou pas…. enfin, bon ça marche comme ça tant qu’il n’existe pas de cartes réseau dont la mac commence en ff, y’a de la marge…)
Pour cela, éditez le script

/etc/xen/scripts/qemu-ifup

et modifier le comme suit

#!/bin/sh

echo -c 'config qemu network with xen bridge for '
echo $*

#patch pcdwarf 
echo "La configuration actuelle de $1 est "
ip link show $1
echo "Passage de la mac de $1 a fe:ff:ff:ff:ff:ff"
ip link set $1 addr fe:ff:ff:ff:ff:ff
echo "La configuration actuelle de $1 est maintenant"
ip link show $1

echo "activation de $1"
ifconfig $1 0.0.0.0 up

echo "Ajout de $1 au bridge $2"
brctl addif $2 $1

#elements facultatifs pour faire du routage
#echo "Activation du proxy ARP pour $1" 
#echo 1 >/proc/sys/net/ipv4/conf/$1/proxy_arp


Les éléments facultatifs pour le routage serviront a faciliter le routage des machines windows mais ne doivent pas être activés sans en comprendre toutes les implications.

La suite un peu plus tard…. 🙂

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

VirtualBox – Gestion de l’usb

 Trucs et astuces techniques  Commentaires fermés sur VirtualBox – Gestion de l’usb
Déc 052010
 

Pour que la gestion de l’usb fonctionne correctement il faut disposer de la version « fermée » de VirtualBox
Il est nécessaire de rebooter (enfin non mais c plus simple) après l’installation du paquet VirtualBox pour que UDEV prenne en compte les modification de règles d’accès des peripheriques usb (accès rw au groupe vboxusers)

Il faut évidemment aussi que l’utilisateur des VM appartienne à ce groupe.

# adduser $username vboxusers