GuiguiAbloc

Ah vous m’avez manqué J’avoue avoir un peu délaissé mon blog dernièrement et a force de me faire houspiller (ah oui, ahan, encore, fais-moi mal (pardon)), je vous propose donc un petit billet technique sous forme d’atelier @home.

Comme vous l’avez deviné au titre  de ce billet (dont le jeu de mot bien pourri est digne de la lignée des meilleurs calembours Carambar), nous allons parler d’IPsec.

Bien évidemment, comme je ne fais pas comme tout le monde, j’ai du faire face à une situation un peu différente de ce que l’on rencontre généralement.

Je dispose @home, derrière la Freeteuse, d’un Cisco PIX, et je souhaite me connecter en IPsec, en mode tunnel (LAN to LAN) sur mes serveurs dédiés sous linux, ou sur des serveurs derrière d’autres équipements (dans le cas de ce billet, me connecter a un réseau local chez un pote derrière un Netopia R9100.

Seul petit point à souligner, je suis en ip dynamique et les autres en ip fixe (ca change ).

Nous allons donc voir  différentes approches d’une connexion IPsec, le Cisco Pix en client, les Linux avec Racoon en serveurs, et le Netopia R9100 en serveur également.

Bien évidemment, comme je ne veux pas exposer les plans d’adressage ip de mon LAN, je vais NATer et filtrer tout ce qui part dans les tunnels.

Un petit dessin valant mieux qu’un grand discours :

Allez, maintenant au boulot.

J’ai décider d’utiliser les plans d’adressages suivant :

10.250.250.0/24 pour NATer mes ressources internes (comment les serveurs de mon LAN sont vus par les autres au travers du tunnel IPsec).

10.40.0.0/24 les ressources du serveur_dédié vu par mon LAN

10.10.150.0/24 les ressources du LAN derrière le Netopia du copain vu depuis mon LAN

Tout ces plans d’adressage vont devenir nos Domaines d’Encryption.

Linux IPsec Tools et RACOON

Sous Linux, la configuration IPsec se fait grace a la suite d’outils IPsec-Tools.

Cette suite d’outil comprend 2 élements importatns :

- Setkey : un outil pour interagir avec la couche ipsec du kernel

- Racoon : un démon IKE pour gérer les clés de connexion IPsec

Sur votre serveur Debian :

apt-get install ipsec-tools racoon

on se créé un fichier /etc/ipsec-tools.conf dans lequel on va détailler notre tunnel IPsec (mode ESP) :

spdadd 10.40.0.0/24 10.250.250.0/24 any -P out ipsec
esp/tunnel/99.99.99.1-0.0.0.0/require;
spdadd 10.250.250.0/24 10.40.0.0/24 any -P in ipsec
esp/tunnel/0.0.0.0-99.99.99.1/require;

Nous définissons donc nos 2 domaines d’encryptions et les deux extrémités du tunnel.

Comme j’ai une ip dynamique, je spéficie 0.0.0.0 (c’est a dire, n’importe qui).

On charge : setkey -f  /etc/ipsec-tools.conf

Vous pouvez jeter un oeil aux SA avec : setkey -D

Pour racoon :

/etc/racoon/racoon.conf
 
...
path pre_shared_key "/etc/racoon/psk.txt";
timer {
phase1 60 seconds ;
phase2 60 seconds ;
}
remote anonymous {
exchange_mode aggressive ;
doi ipsec_doi ;
situation identity_only ;
lifetime time 1 hour ;
generate_policy on;
passive on;
my_identifier address 99.99.99.1 ;
peers_identifier fqdn "pix.guiguiabloc.fr" ;
proposal {
encryption_algorithm aes 256;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
proposal_check obey ;
}
sainfo anonymous {
pfs_group modp1024;
lifetime time 1 hour ;
encryption_algorithm aes 256;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}

Explication :

On défini ici les différents paramètres de sécurité du tunnel pour les Phase 1 (IKE) et 2 (IPsec) a savoir les méthodes de chiffrement, de hachage, les temps de vie, l’activation du PFS (pour échanger des clés supplémentaires ) etc…

Je ne vais pas entrer dans les détails d’IPsec, donc un peu de lecture :

http://www.securiteinfo.com/cryptographie/IPSec.shtml

http://www.tcpipguide.com/free/t_IPSecurityIPSecProtocols.htm

La partie importante qui nous intéresse ici est le mode « Agressive » et non « Main ». En effet, j’ai une ip dynamique et je ne peux donc pas me baser dessus pour la négociation. J’utilise donc le fqdn de mon Pix (pix.guiguiabloc.fr) comme identifiant, et pour faire du fqdn+ pre-shared key, bah il faut etre en mode Agressive

Enfin dans le fichier /etc/racoon/psk.txt je renseigne la Pre-shared key (le mot de passe si vous préférez) :

pix.guiguiabloc.fr motdepassesupersecretamoi

Vous pouvez lancer Racoon : /etc/init.d/racoon start et le démon doit écouter sur les ports UDP 4500 et 500.

NETOPIA R9100

Le Netopia R9100 est un vieux routeur qui fait papa/maman. On peut le retrouver dans certaines TPE/PME ou chez des potes Geek qui font de la récupération :p , c’est le cas ici.

Ouf….

Allez on s’occupe de la maison.

On NAT notre pc 192.168.100.1 en une ip du domaine d’encryption

r-backbone
 
int fa 0/0 (interne)
 
ip nat inside
 
int fa 0/1 (externe)
 
ip nat outside
 
ip nat inside source static 192.168.100.1 10.250.250.1
 
ip route 10.250.250.0 255.255.255.0 FastEthernet0/0

On route les domaines d’encyptions des serveurs distants :

ip route 10.40.0.0 255.255.255.0 10.254.254.254
 
ip route 10.10.150.0 255.255.255.0 10.254.254.254
 
Coeur de Réseau
 
ip route 10.40.0.0 255.255.255.0 10.144.1.254
 
ip route 10.10.150.0 255.255.255.0 10.144.1.254

Cisco PIX

# Les ACLS qui vont bien
access-list outside-ipsec extended permit ip 10.250.250.0 255.255.255.0 10.10.150.0 255.255.255.0
access-list outside-ipsec extended permit ip 10.250.250.0 255.255.255.0 10.40.0.0 255.255.255.0
 
access-list outside_serveur extended permit ip 10.250.250.0 255.255.255.0 10.40.0.0 255.255.255.0
access-list outside-pote extended permit ip 10.250.250.0 255.255.255.0 10.10.150.0 255.255.255.0
 
 
# on ne natte pas les ips des domaines d'encryption
 
nat (inside-test) 0 access-list outside-ipsec
 
# La partie IPSEC elle meme
 
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map map-ipsec 1 match address outside_serveur
crypto map map-ipsec 1 set pfs
crypto map map-ipsec 1 set peer 99.99.99.1
crypto map map-ipsec 1 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5
crypto map map-ipsec 1 set nat-t-disable
crypto map map-ipsec 1 set phase1-mode aggressive
crypto map map-ipsec 20 match address outside-pote
crypto map map-ipsec 20 set pfs
crypto map map-ipsec 20 set peer 88.88.88.88
crypto map map-ipsec 20 set transform-set ESP-3DES-SHA
crypto map map-ipsec 20 set nat-t-disable
crypto map map-ipsec 20 set phase1-mode aggressive
crypto map map-ipsec interface outside
crypto isakmp identity hostname
crypto isakmp enable outside
crypto isakmp policy 5
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 10
authentication pre-share
encryption des
hash sha
group 2
lifetime 86400
crypto isakmp policy 20
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400
 
group-policy IPSEC_POLICY internal
group-policy IPSEC_POLICY attributes
vpn-filter none
vpn-tunnel-protocol IPSec
tunnel-group 99.99.99.1 type ipsec-l2l
tunnel-group 99.99.99.1 general-attributes
default-group-policy IPSEC_POLICY
tunnel-group 99.99.99.1 ipsec-attributes
pre-shared-key *
tunnel-group 88.88.88.88 type ipsec-l2l
tunnel-group 88.88.88.88 general-attributes
default-group-policy IPSEC_POLICY
tunnel-group 88.88.88.88 ipsec-attributes
pre-shared-key *

N’oubliez pas que vous ne pouvez avoir qu’1 crypto map par Interface, il faut donc juste rajouter un identifant numerique supplémentaire pour chaque nouveau tunnel (ici 1 pour le premier tunnel, 20 le deuxieme).

Et beh..

Allez maintenant on test :

ssh 10.10.150.1

Mar 27 18:12:58 pix Mar 27 2011 18:12:58: %PIX-5-713041: IP = 88.88.88.88, IKE Initiator: New Phase 1, Intf inside-test, IKE Peer 88.88.88.88  local Proxy Address 10.250.250.0, remote Proxy Address 10.10.150.0,  Crypto map (map-ipsec)
Mar 27 18:13:01 pix Mar 27 2011 18:13:01: %PIX-6-713219: IP = 88.88.88.88, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Mar 27 18:13:07 pix Mar 27 2011 18:13:07: %PIX-6-713219: IP = 88.88.88.88, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-6-113009: AAA retrieved default group policy (IPSEC_POLICY) for user = 88.88.88.88
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-5-713119: Group = 88.88.88.88, IP = 88.88.88.88, PHASE 1 COMPLETED
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-3-713122: IP = 88.88.88.88, Keep-alives configured on but peer does not support keep-alives (type = None)
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-6-713220: Group = 88.88.88.88, IP = 88.88.88.88, De-queuing KEY-ACQUIRE messages that were left pending.
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-5-713073: Group = 88.88.88.88, IP = 88.88.88.88, Responder forcing change of IPSec rekeying duration from 28800 to 3600 seconds
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-5-713049: Group = 88.88.88.88, IP = 88.88.88.88, Security negotiation complete for LAN-to-LAN Group (88.88.88.88)  Initiator, Inbound SPI = 0xe4e88f39, Outbound SPI = 0x94160878
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-6-602303: IPSEC: An outbound LAN-to-LAN SA (SPI= 0x94160878) between 192.168.1.250 and 88.88.88.88 (user= 88.88.88.88) has been created.
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-6-602303: IPSEC: An inbound LAN-to-LAN SA (SPI= 0xE4E88F39) between 192.168.1.250 and 88.88.88.88 (user= 88.88.88.88) has been created.
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-5-713120: Group = 88.88.88.88, IP = 88.88.88.88, PHASE 2 COMPLETED (msgid=f0cb61bd)

Rhââ Lovely

Idem l’autre tunnel avec un ping 10.40.0.1 par exemple

Si vous voulez filtrer les paquets dans vos tunnels ipsec, utilisez des ACLS de type :

access-list acl-ipsec extended permit tcp 10.40.0.0 255.255.255.0 eq www 10.250.250.0 255.255.255.0 gt 1023

(le reseau distant d’abord, puis votre propre reseau ensuite).

Dans le Pix, modifier l’éntrée vpn-filter none par :

vpn-filter value acl-ipsec

Amusez vous bien

Ayant récemment commandé 2 serveurs dédiés chez OVH (des EG Best-of pour les curieux dont vous trouverez le détail ICI ), dans le but d’en faire un cluster Haute-disponibilité, voici un « petit » tuto et retour d’expérience.

Les configs qui suivent sont spécifiques à OVH pour la partie IP FailOver (ip load balancée) et la compilation du noyau pour DRBD mais le reste peut s’adapter à d’autres hébergeurs bien sûr (i.e Dedibox par exemple).

Je ne rentrerais pas dans le troll de pourquoi OVH et pas Dédibox, mais j’ai un « gros » faible pour OVH qui avec son Directeur Général des plus actifs, présent sur les forums (Octave Klaba aka Oles, le fils d’Henryk, le fondateur d’OVH (un chti lien), voila pour la partie People), une communauté de passionnés et des services hallucinant ont naturellement fait que je les préfère à son « concurrent » direct. Bref, je suis et connais OVH depuis sa « naissance » et ils ont prouvés depuis longtemps leur statut. Les agitateurs de l’hébergement c’est eux comme Free pour les FAI, mais cela reste ma propre opinion , et puis tout le monde a ses défauts

Donc suite a l’acquisition de ses 2 serveurs, voici les contraintes que je me suis imposées :

• IP virtuelle basculable d’un serveur à l’autre
• Partition synchronisée en temps réel et utilisable par simple bascule sur un serveur ou sur l’autre
• Interruption de service < 300 secondes
• Automatisation de la bascule
• Cryptage des flux réseaux entre les 2 serveurs
• Alerte par Texto + Mail sur mon téléphone portable en cas de bascule

Bien évidemment, les surveillances Nagios des 2 serveurs ne seront pas évoqués ici, c’est de la routine (en mode nsca crypté hein )

Je partirai du principe que mes serveurs s’appellent ns11111 et ns22222 (nsxxxx.ovh.net étant le hostname par défaut des serveurs d’OVH, a changer bien entendu rapidement et positionner un reverse également).

On va considérer que ns11111 a l’ip 192.168..20.20 et ns22222 192.168.20.30 (c’est juste pour l’exemple hein, je vais pas mettre d’ip publiques dans le tuto vous changer par l’ip publique principale de votre serveur = eth0

On est parti, phase 1.

• Configuration d’un tunnel VPN IPSEC en mode transport

Pour que les échanges d’information réseau entre les deux serveurs dédiés soient un minimum sécurisé (comprendre difficilement « sniffable »), j’ai décider de monter un tunnel VPN en IPSEC entre les deux.

Les serveurs sont sous Debian Etch. (vous adapter si vous avez un autre OS)

IPSEC autorise 2 modes de communication le mode tunnel (1 serveur/réseau vers 1 réseau) et le mode Transport (1 serveur vers 1 serveur) (en résumé hein, venez pas me saouler avec mon simplicisme )

Donc le mode transport.

apt-get install ipsec-tools

on se configure le /etc/ipsec-tools.conf sur les deux serveurs.

ns11111 :

#!/usr/sbin/setkey -f 

flush;

spdflush;

# AH

add 192.168.20.30 192.168.20.20 ah 15700 -A hmac-md5 "1234567890123456";

add 192.168.20.20 192.168.20.30 ah 24500 -A hmac-md5 "1234567890123456";

# ESP

add 192.168.20.30 192.168.20.20 esp 15701 -E 3des-cbc "123456789012123456789012";

add 192.168.20.20 192.168.20.30 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 192.168.20.20 192.168.20.30 any -P out ipsec

           esp/transport//require

           ah/transport//require;

spdadd 192.168.20.30 192.168.20.20 any -P in ipsec

           esp/transport//require

           ah/transport//require;

ns22222 :

#!/usr/sbin/setkey -f 

flush;

spdflush;

# AH

add 192.168.20.30 192.168.20.20 ah 15700 -A hmac-md5 "1234567890123456";

add 192.168.20.20 192.168.20.30 ah 24500 -A hmac-md5 "1234567890123456";

# ESP

add 192.168.20.30 192.168.20.20 esp 15701 -E 3des-cbc "123456789012123456789012";

add 192.168.20.20 192.168.20.30 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 192.168.20.30 192.168.20.20 any -P out ipsec

        esp/transport//require

 ah/transport//require;

spdadd 192.168.20.20 192.168.20.30 any -P in ipsec

           esp/transport//require

           ah/transport//require;

Vous remarquerez que les changements portent sur les sens de trafic.

Bien évidemment, vous changez les clés (32 octets hexadecimaux, et 48 pour les clés 3des-cbc), générable faisable facilement par un :

hexdump -e ‘8/2 “%04x” ‘ /dev/urandom -n 16; echo (pour les 32 caractères)

hexdump -e ‘8/2 “%04x” ‘ /dev/urandom -n 24; echo (pour 48)

Exemple :

hexdump -e ‘8/2 « %04x » ‘ /dev/urandom -n 16; echo
6e99170129b4bc1b774161f0c7ecf50f

la clé = 0×6e99170129b4bc1b774161f0c7ecf50f (sans les guillemets).

Un ping vers l’autre serveur et un tcpdump vous démontreront le cryptage effectif :

# tcpdump -n "host 192.168.20.30"

01:23:27.996891 IP 192.168.20.20 > 192.168.20.30: AH(spi=0x00000302,seq=0x1): ESP(spi=0x00000303,seq=0x1), length 88

01:23:27.998282 IP 192.168.20.30 > 192.168.20.20: AH(spi=0x00000202,seq=0x277ac2): ESP(spi=0x00000203,seq=0x277ac2), length 88

01:23:28.999853 IP 192.168.20.20 > 192.168.20.30: AH(spi=0x00000302,seq=0x2): ESP(spi=0x00000303,seq=0x2), length 88

01:23:29.001726 IP 192.168.20.30 > 192.168.20.20: AH(spi=0x00000202,seq=0x277ac3): ESP(spi=0x00000203,seq=0x277ac3), length 88

4 packets captured

15653 packets received by filter

0 packets dropped by kernel

Un petit Mémo Ipsec ICI.

Comme nous ne faisons que du 1 pour 1, inutile de se fatiguer à installer une gestion des clés (type isakmpd ou Racoon).

NB : Pour sécuriser tout cela, vous peaufiner votre Iptables pour n’accepter que du trafic Ipsec entre les deux serveurs.

• DRBD

Pour ceux qui ne connaissent pas DRBD, il s’agit en résumé d’un RAID 1 sur IP. Comprendre une synchronisation de deux partitions via le réseau en mode bloc.

Je vous invite à consulter l’excellent site www.drbd.org pour en savoir plus.

Le noyau par défaut des serveurs OVH n’inclus pas le support des modules. Il faut donc le recompiler et également ajouter le driver Connector.

- Récupérer les sources du Kernel

cd /usr/src/
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.24.5-ovh.tar.bz2
tar -jxvf linux-2.6.24.5-ovh.tar.bz2
ln -s linux-2.6.24.5-ovh linux

- Récuperer le .config standard

wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-32
cp 2.6-config-xxxx-std-ipv4-32 linux/.config
cd linux

- Recompiler le noyau

make menuconfig (ou votre méthode préférée).

Activer le support des modules :
« Enable loadable module support » -> « Module unloading » et « Automatic kernel module loading »

Activer le kernel userspace connector:

Device Drivers —> Connector – unified userspace <-> kernelspace linker

make
make modules_install
cp arch/i386/bzimage /boot/vmlinux-2.6.24.5-xxxx-std-ipv4-32
cp Sytem.map /boot/System.map-2.6.24.5-xxxx-std-ipv4-32

Editer lilo.conf ou menu.lst de Grub pour pointer sur le bon kernel.

lilo -v -v ou grub-install hd0

Rebooter.

- DRBD

wget http://oss.linbit.com/drbd/8.0/drbd-8.0.13.tar.gz
tar xzvf drbd-8.0.13.tar.gz
cd drbd-8.0.13
cd drbd
make
cd ..
make tools
make install
make install-tools

Editer votre /etc/drbd.conf

(A adapter à votre configuration bien sur) :

#
# drbd.conf
#
global {
usage-count yes;
}

common {
syncer { rate 20M; }
}

resource r0 {

protocol C;

handlers {
pri-on-incon-degr « echo o > /proc/sysrq-trigger ; halt -f »;
pri-lost-after-sb « echo o > /proc/sysrq-trigger ; halt -f »;
local-io-error « echo o > /proc/sysrq-trigger ; halt -f »;
outdate-peer « /usr/lib/heartbeat/drbd-peer-outdater -t 5″;
}

startup {
degr-wfc-timeout 120; # 2 minutes.
}

disk {
on-io-error detach;
}

net {
after-sb-1pri disconnect;
after-sb-2pri disconnect;
rr-conflict disconnect;
}

syncer {
rate 20M;
al-extents 257;
}

on ns11111 {
device /dev/drbd0;
disk /dev/sda10;
address 192.168.20.20:7788;
meta-disk internal;
}

on ns22222 {
device /dev/drbd0;
disk /dev/sda10;
address 192.168.20.30:7788;
meta-disk internal;
}
}

NB: Vous verrouillez le port 7788 dans Iptables bien sûr…

(en cas de soucis avec une partition prélablement créée, il suffit de passer un : dd if=/dev/zero bs=1M count=1 of=/dev/sdaX; sync )

A faire sur chacun des noeuds :

drbdadm create-md r0
modprobe drbd
drbdadm attach r0
drbdadm connect r0
cat /proc/drbd

/etc/init.d/drbd start
Sur le serveur primaire : drbdadm — –overwrite-data-of-peer primary r0
Pour suivre la synchro initiale :

cat /proc/drbd
Vous pouvez formater la partition :

mkfs.ext3 /dev/drbd0

Je vous invite à consulter Google pour pousser plus en avant votre compréhension de DRBD.

• Heartbeat

Heartbeat est un système de prise de pouls pour un cluster (définition détaillée ICI).

Il se charge de surveiller son « confrère » et d’executer certains commandes pré-définis en cas de perte de l’un des noeuds.

Sur les 2 serveurs :

apt-get install heartbeat

Créer le fichier /etc/ha.d/ha.cf :

ucast eth0 192.168.20.30 (pour ns11111, 192.168.20.20 pour ns22222)
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
# Délai entre deux battements de pouls
keepalive 2
# Temps nécessaire avant de considérer un noeud comme mort
deadtime 30
# délai avant d'envoyer un avertissement pour les pouls en retard
warntime 6
# deadtime spécifique pour les conf ou le reseau met du temps a démarrer
initdead 60
# port a utiliser pour la prise de pouls
udpport 694
# uname -n pour connaitre le nom des serveurs
node ns11111.ovh.net
node ns22222.ovh.net
# met la valeur on, pour master auto
auto_failback off

Créer le fichier /etc/ha.d/authkeys :

auth 1
1 md5 "supermotdepasse"
2 crc

chmod 600 /etc/ha.d/authkeys

La partie la plus importante maintenant, les scripts à lancer :

/etc/ha.d/haresources :

ns11111.ovh.net IPaddrFO::10.10.10.10/32/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/data::ext3

Petite explication sur cette ligne :

On spécifie tout d’abord le noeud Maître, ici ns11111.

Puis on utilise le script IPaddrFO (on va voir cela après) pour monter l’adresse IP 10.10.10.10 en masque 255.255.255.255 sur eth0

Puis on définie le DRBD comme Primaire et on monte la partition DRBD dans /data en type ext3.

Si le Maitre (ns11111) tombe, alors ns2222 devient le nouveau maitre et récupère l’adresse IP et la partition.

IPaddrFO est en fait une copie de /etc/ha.d/ressource.d/IPaddr que j’ai un peu modifier… (on voit cela plus bas).

• IPFailOver

Chez OVH, vous avez la possibilité de disposer d’ips « failover ». Explication ICI.

L’ipfailover est routée sur l’un ou l’autre des serveurs selon votre choix dans le « Manager », l’interface d’administration de votre compte OVH.

J’ai donc tout d’abord demander une IP failover pour mon serveur ns11111.ovh.net. Cette IP est 10.10.10.10 dans mon exemple.

Elle est routée sur 192.168.20.20.

Et là vous me dites « ahan mais c’est nul, t’es obligé d’aller dans ton interface pour affecter la nouvelle redirection, SAPU !!! Je vais pas faire ça a la main moi !!! »

Et ben non, jeune Padawan, on vas automatiser tout cela grace à…. SOAP.

Car OVH propose des API SOAP pour attaquer directement l’interface via un script perl, php, C ou python… Fort non ?

Le site est ici : http://www.ovh.com/soapi/fr/

Perso, j’ai choisi Python. Parce que Pyhon, SAYBIEN et pis c’est tout.

On a juste besoin de Python (dingue non ?) et de soappy suur les serveurs.

apt-get install python-soappy python

Le script que j’utilise :

ns11111-failoverupdate.py :

#!/usr/bin/python

from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/ovh.wsdl')

#login
nic = 'monlogin-ovh'
password = 'xxxxxxx'

try:
 session = soap.login( nic, password )
 print "login successfull"
except:
 print "Error login"

#dedicatedFailoverUpdate
try:
 result = soap.dedicatedFailoverUpdate( session, 'ns11111.ovh.net', '10.10.10.10', '192.168.20.20' );
 print "dedicatedFailoverUpdate successfull";
 # your code here ...
except:
 print "Error dedicatedFailoverUpdate"

#logout
try:
 result = soap.logout( session )
 print "logout successfull"
except:
 print "Error logout"

ns22222-failoverupdate.py :

#!/usr/bin/python

from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/ovh.wsdl')

#login
nic = 'monlogin-ovh'
password = 'xxxxx'

try:
 session = soap.login( nic, password )
 print "login successfull"
except:
 print "Error login"

#dedicatedFailoverUpdate
try:
 result = soap.dedicatedFailoverUpdate( session, 'ns11111.ovh.net', '10.10.10.10', '192.168.20.30' );
 print "dedicatedFailoverUpdate successfull";
 # your code here ...
except:
 print "Error dedicatedFailoverUpdate"

#logout
try:
 result = soap.logout( session )
 print "logout successfull"
except:
 print "Error logout"

Explication sur la ligne « soap.dedicatedFailoverUpdate » :

Le premier champ correspond au hostname OVH sur serveur sur lequel vous avez pris (comprendre commander) votre ip failover. Ici ns11111.ovh.net

Ensuite l’ip failover elle même.

Puis l’ip sur laquelle router la failover .

Facile non ?

On se modifie notre script /etc/ha.d/ressource.d/IPaddrFO (copie de IPaddr) :

A la fin :

case $2 in
  start)        /etc/ha.d/ns11111-failoverupdate.py
                ip_start $1;;
  stop)         /etc/ha.d/ns22222-failoverupdate.py
                ip_stop $1;;
  status)       ip_status $1;;
  monitor)      ip_monitor $1;;
  *)            usage
                exit 1
                ;;
esac

Vous inverser les scripts sur ns2222 bien sûr…

Vous pouvez maintenant lancer heartbeat sur ns1111 puis sur ns2222 et vous devriez voir les annonces défilaient dans le syslog et l’ipfailover monté sur ns11111 ainsi que le partition /data en DRBD.

Un reboot de ns11111 et l’ip failover bascule sur ns22222, la partition /data en DRBD monte et le script python force l’update du failover sur l’interface OVH.

Après de multiples tests, le plus long est cette mise à jour dans l’interface, dans l’ensemble les 2 serveurs mettent quelques secondes à basculer mais la mise à jour prend entre 60 et 90 secondes.

Ce qui entraine une indispo maximum d’1 minute 30. Ca va encore hein

Dernière chose, l’alerte SMS

Alors là, je me suis pas foulé , autant utiliser les services de nos opérateurs de téléphonie mobile.

Etant chez SFR, je peux me créer une BAL type @sfr.fr consultable sur leur Webmail : http://sfr-messagerie.fr

Le petit plus de cette BAL c’est que lorsque vous recevez un email sur cette adresse, vous recevez un texto sur votre mobile avec le sujet du mail

Il n’en faut pas plus pour être alerté par SMS en temps quasi réel.

On ajoute une entrée dans le /etc/ha.d/haresources (sur les deux serveurs) :

ns11111.ovh.net IPaddrFO::10.10.10.10/32/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/data::ext3 MailTo::monadresse@sfr.fr::Alerte_Bascule

De plus, OVH vous envoie un email quand vous forcer l’update de l’ipfailover, si avec tout ca, vous n’etes pas informé que votre cluster à basculer…

Petite précision, dans ma configuration, j’empeche le serveur ns11111 de redevenir Maître automatiquement quand il revient (en cas de soucis électrique ou reboot en boucle par exemple), c’est a vous de vérifier que tout va bien sur ns1111 et de lancer un simple « /etc/init.d/heartbeat restart » sur ns22222 pour que les noeuds repassent en mode master/slave comme à l’origine.

Voila, une petite architecture poilue comme je l’aime

En espérant vous avoir apporter des idées et vous donner envie de découvrir Heartbeat et DRBD, car bien sur, dans mon exemple, je ne parle pas des relances de services type Mysql ou Apache en mode « cluster »

EDIT : Suite aux différents tests via Ipsec, je vous conseille fortement d’utiliser l’algo AES plutot que 3DES pour l’ESP. Donc profiter la recompilation de votre noyau pour inclure le support crypto AES (désactivé par défaut dans la config OVH) et modifier vos conf ipsec-tools.conf ainsi :

add 192.168.20.30 192.168.20.20 esp 15701 -E rijndael-cbc "123456789012123456789012";