Bridge automatique au dessus d'un tunnel OpenVPN

Certains diront que j'aime me compliquer la vie...

Le contexte est assez particulier :

  • n serveurs accessibles via une adresse publique.
  • un bridge OpenVPN est mis en place afin de permettre une communication privée ; il s'agit d'émuler l'existence d'une DMZ virtuelle.
  • ces serveurs seront des serveurs de virtualisation.
  • les hôtes virtualisés doivent pouvoir communiquer sans restriction, comme dans une DMZ.

 

Bref, une bonne grosse accumulation de couche avec une accumulation de 2 bridges : le premier pour l'interface réel, le second sur l'interface sur le tunnel OpenVPN.

Mais finalement, avec les bons outils on arrive relativement aisément au résultat attendu. 

Tout d'abord, on définit le bridge sur l'interface réel afin de pouvoir utiliser OpenVPN en mode bridge. Pour cela, rendez-vous dans /etc/network/interfaces:

...
 
iface eth0 inet manual
 
auto www
iface www inet static
bridge_ports eth0
address x.x.x.x
netmask x.x.x.x
network x.x.x.x
broadcast x.x.x.x
gateway x.x.x.x

 

Ensuite, placez le script suivant dans le répertoire /etc/openvpn/.

#!/bin/sh
 
BRIDGE_NAME=`basename ${config} | cut -d "." -f 1`
SCRIPT_NAME=$0
 
case ${script_type} in
   "up")
      logger -p daemon.notice -i ${SCRIPT_NAME} "Bridging up ${dev} into ${BRIDGE_NAME}"
      brctl addbr ${BRIDGE_NAME}
      brctl addif ${BRIDGE_NAME} ${dev}
 
      /sbin/ifconfig ${dev} 0.0.0.0 promisc up
      /sbin/ifconfig ${BRIDGE_NAME} ${ifconfig_local} ${ifconfig_netmask} up
      exit 0
   ;;
 
   "down")
       logger -p daemon.notice -i ${SCRIPT_NAME} "Destroying ${BRIDGE_NAME} bridge"
       /sbin/ifconfig ${BRIDGE_NAME} down
       brctl delbr ${BRIDGE_NAME}
       exit 0
   ;;
 
   *)
      logger -p daemon.notice -i ${SCRIPT_NAME} "WARN : Script of type ${script_type} is not supported. If VPN ${config} does not work please restart"
      exit 1
   ;;
esac

 

Ce script va monter un bridge au dessus du tunnel OpenVPN courant. Pas besoin de configuration, le nom et les paramètres réseaux sont recopiés entre le tunnel et le bridge. Il ne reste plus que la configuration du tunnel. Dans mon exemple il s'agit du fichier /etc/openvpn/backbone.conf :

remote x.x.x.x
port 1294
client
dev tap
fast-io
 
up handle-bridge
down handle-bridge
 
ca backbone-pki/cacert.pem
cert backbone-pki/gaia.pem
key backbone-pki/gaia.insecure.key
 
dh backbone-pki/dh1024.pem
 
keepalive 10 60
 
persist-tun
persist-key
 
server 192.168.200.0 255.255.255.0
client-to-client

Voilà!

 

IPv6 addrconf: prefix with wrong length 56

 Problème récurrent sur les serveurs dédiés OVH. Vu que je n'ai pas besoin d'IPV6, on va le désactiver au niveau du boot.

Dans le fichier /boot/grub/menu.lst, rajoutez l'option ipv6.disable=1. Dans mon cas, ça donne : 

# kopt=root=/dev/md1 ro md=1,/dev/sda1,/dev/sdb1 ipv6.disable=1

Le '#' est important. Ensuite, il ne reste qu'à mettre à jour la configuration GRUB et de rebooter

 

Kernels Ubuntu et serveurs dédiés OVH (RAID)

Ceux qui ont déjà administrés des serveurs dédiés OVH auront sans doute remarqué la présence des kernels made in OVH. En effet, quelque soit la distribution utilisée, un serveur OVH sera toujours livré par défaut avec un des kernels customisés et packagés par OVH. Au programme : 32 ou 64 bits, support IPV6, fréquence de 100 Hz mais on retiendra surtout une compilation des drivers en dur au sein du kernel.

Si je comprends les raisons de ce choix - facilité d'administration et de déploiement - et que je loue la présence de ces kernels tout terrain lors de l'utilisation du netboot, j'aime pouvoir m'affranchir de cette restriction. Et c'est là que problèmes commencent. Nous, administrateurs systèmes en herbe, sommes aujourd'hui tellement assistés par les programmes d'installation - ça fait bien longtemps qu'une distribution Linux est plus facile à installer qu'un Windows -  qu'on ne saisit par toujours les implications de certains choix techniques. Exemple le plus répandu chez OVH : le boot sur du RAID.

Chez OVH, il est activé out-of-the-box sur toute l'offre. Les kernels made in OVH supportent donc ce mode de fonctionnement. C'est lorsque que l'on veut repasser au kernel standard de la distribution que les choses se compliquent...

Améliorer les performances de Firefox 3

Les utilisateurs des logiciels sont exigeants et ce n'est pas les utilisateurs Linux qui changent la donne. Firefox, avec toutes ses qualités et son importance dans la guerre des navigateurs n'est pas une exception à la règle et subit régulièrement les foudres de la communauté. Ces critiques portent essentiellement sur les performances de Firefox.

Redimensionnement des images NTFS (Xen, KVM, Qemu, whatever)

Bon d'accord, une note similaire est déjà disponible - Redimensionnement des images Xen - ; mais cette fois-ci ça se complique :

Pièces jointes winmail.dat

Le fichier winmail.dat est un fichier d'encapsulation des pièces jointes d'un mail. Il est généré par Outlook lorsque votre correspondant envoie son message au format RTF. 2 actions lorsque l'on reçoit ces fichiers :

Cumulus Tag Cloud