GuiguiAbloc

Petit billet rapide suite à la sortie de l’offre MiniCloud d’OVH http://www.kimsufi.com/cloud/

Bien évidemment, cette technique ne s’applique pas seulement à cette offre, elle est juste… bien utile.

En effet, les MiniCloud d’OVH changent d’adresse IP quand on les éteints et qu’on les rallument. C’est assez gênant de courir après la nouvelle adresse ip du cloud n°24, mais heureusement, afin d’éviter ceci, le DNS est notre ami.

Vous connaissez tous DynDNS, un service gratuit, très utilisé par les gens qui disposent d’une adresse IP dynamique chez eux, et qui permet, lors du changement d’adresse, de mettre a jour une entrée DNS de type chezmoi.dyndns.com.

Ce que je vous propose, c’est de faire la même chose sur vos serveurs DNS, et donc de changer dynamiquement une entrée de type A en cas de changement d’adresse IP (de votre MiniCloud par exemple).

Je considère déjà que vous savez comment fonctionne un DNS et que le votre est fonctionnel et opérationnel pour votre ou vos domaines.

• BIND

Pré-requis, les packages dns-utils et bind9  (pour les distributions Debian)

Première étape, créer une paire de clés pour permettre de mettre à jour le DNS à distance en toute sécurité :

dnssec-keygen -a HMAC-MD5 -b 512 -n USER -r /dev/urandom dnscloud.guiguiabloc.fr
Kdnscloud.guiguiabloc.fr.+157+06250

Vous avez désormais 2 clés, 1 privée et 1 publique (comme pour ssh)

serveur:~# ll K*
-rw------- 1 root root 130 jun  1 09:41 Kdnscloud.guiguiabloc.fr.+157+06250.key
-rw------- 1 root root 156 jun  1 09:41 Kdnscloud.guiguiabloc.fr.+157+06250.private

On récupère la clé :

serveur:~# cat Kdnscloud.guiguiabloc.fr.+157+06250.private | grep Key
Key: GaC4ezsL0c/gWqG7nzH4iYyWPqYS2tC3H78ZYkyuvj5LJyq6JZjh4f+KKhuL/A5gTnc1K0rRw2u/3z+eXA76XA==

Ajouter la clé dans le fichier named.conf (ou named.conf.local tout dépend de votre façon de travailler ) :

key "dnscloud.guiguiabloc.fr." {
   algorithm hmac-md5;
   secret "GaC4ezsL0c/gWqG7nzH4iYyWPqYS2tC3H78ZYkyuvj5LJyq6JZjh4f+KKhuL/A5gTnc1K0rRw2u/3z+eXA76XA==";
   };

Ensuite, nous allons autoriser cette clé a mettre à jour notre domaine (ou sous-domaine si vous avez séparé vos entrées)

zone "guiguiabloc.fr" {
type master;
file "/etc/bind/zone.guiguiabloc.fr";
allow-update { key dnscloud.guiguiabloc.; };
allow-query { any; };
};

Dans votre fichier de zone, ajouter votre entrée de type A :

$TTL 180        ; 3 minutes
cloud01                 A       91.12.34.56

Vous remarquerez que je force un TTL a  180 secondes (important, par défaut les entrées sont valables 24h…)

On reload Bind et on tente une mise à jour à distance :

serveur# nsupdate -d -k ./Kdnscloud.guiguiabloc.fr.+157+06250.private
   Creating key...
   > server ns.guiguiabloc.org.
   before getaddrinfo()
   > update delete cloud01.guiguiabloc.org.
   > update add cloud01.guiguiabloc.org. 180 A 212.56.43.21
   > send
...
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  60872
;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
cloud1.guiguiabloc.fr.     0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 1275379509 300 16 X3gUWw/uLyIJL4RykJbp24w== 60872 NOERROR 0

Et dans les logs de votre serveur Bind :

Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: signer "dnscloud.guiguiabloc.fr" approved
Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: updating zone 'guiguiabloc.fr.fr/IN': delete all rrsets from name 'cloud01.guiguiabloc.fr'
Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: updating zone 'guiguiabloc.fr/IN': adding an RR at 'cloud01.guiguiabloc.fr' A

Magique

Ne reste qu’a scripter tout cela.

2 techniques pour récuperer l’ip (a vous de choisir celle qui vous convient ) :

1. On se créer une petite page php sur un de nos serveurs web qui nous donne l’ip depuis la laquelle nous nous présentons :

cat index.php
 
<?PHP
echo $_SERVER["REMOTE_ADDR"];
?>

On l’héberge sur un nom style ip.guiguiabloc.fr et il suffit d’appeler (via Curl) l’adresse ip.guiguiabloc.fr pour récuperer notre ip fixe.

1. On récupère l’adresse IP via ifconfig

ifconfig eth0 | egrep 'inet adr:'| cut -d: -f2 | awk '{ print $1}'

Le script :

cloud# cat update_cloud.sh
#!/bin/bash
IP=`curl -s ip.guiguiabloc.fr`
 
# Si ifconfig
 
# IP=`ifconfig eth0 | egrep 'inet adr:'| cut -d: -f2 | awk '{ print $1}'`
 
# check si changement
ACTUALIP=`/usr/bin/dig +short cloud01.guiguiabloc.fr @ns.guiguiabloc.fr | /usr/bin/tail -n1 `
 
if test "$ACTUALIP" = "$IP"
then exit 0
else
 
cat > /var/scripts/majdnscloud.txt << EOF
server ns.guiguiabloc.fr
zone guiguiabloc.fr
update delete cloud01.guiguiabloc.fr. A
update add cloud01.guiguiabloc.fr. 180 A $IP
show
send
EOF
 
nsupdate -k /var/scripts/Kdnscloud.guiguiabloc.fr.+157+06250.private -v /var/scripts/majdnscloud.txt
fi

Et hop, on se met a au démarrage du cloud (genre a la fin et rc.local) et au reboot du cloud, le dns sera mis automatiquement à jour.

• DJBDNS

Si vous n’utilisez pas Bind mais l’excellent DJBDNS, il existe un tutorial très bien fait pour appliquer la même technique :

http://qmail.jms1.net/djbdns/dyndns.shtml

Voilà, j’espère que cette technique vous servira, non seulement pour vos serveurs amenés à changer d’adresse IP, mais également chez vous, si vous avez une IP dynamique et vous souhaitez utiliser vos propres noms de domaines.

Amusez vous bien

Tout le monde le sait, on ne cesse de nous rabâcher la même prophétie, bientôt c’est la fin du monde !!!

Enfin, outre la fameuse année 2012, qui a déjà pris de l’avance sur le site http://www.2012fin.com (n’y aller pas !! en plus il est vérolé !!!) si j’en crois le résultat suivant :

C’est surtout la diminution constante des adresses IPv4 publiques disponibles qui continue son oeuvre.

Bien évidemment, depuis quelques années déjà, IPv6 est la réponse a ce problème, mais bon, cela ne sera pas en place partout avant bien longtemps, donc pas de cris paniqués, de viols incongrus, d’immolations inconsidérées ou de bitures monumentales (euh quoique…), IPv4 a encore de beaux jours devant lui.

Quoi qu’il en soit, il était temps de me dépoussiérer un peu et de replonger dans les méandres d’IPv6 et de remettre cela en oeuvre dans mon architecture.

Mes connaissances en IPv6 étant plus qu’anciennes, je me suis donc remis à niveau à coup de lecture multiples sur des sites divers et variés, allant des RFC aux blogs.

La liste étant particulièrement imposante, je vous laisse plutôt vous promener sur Google.

Un des sites les plus amusants pour se remettre a niveau est Hurricane Electric, un provider Internet et également Tunnel Broker IPv6, qui vous propose de passer votre Certification IPv6 à travers une série de questionnaire et d’exercices pratiques a mettre en place (exemple vous rendre sur le site via une connexion IPv6, monter un MX IPv6, des DNS IPv6 etc…), bref des étapes amusantes qui vous permettent de progresser dans votre apprentissage/remise à niveau, tout en maquettant votre future architecture.

Pour la Certification, cela se passe la : http://ipv6.he.net/certification/

Au fur et a mesure vous changez de niveau (newbie, explorer, enthusiast, administrator, professional, guru et enfin sage). Validé bien sûr par un « zoli » diplôme et un lien vers vos résultats a mettre sur votre site :

ah ah ah

Bref, très instructif et amusant pour bosser IPv6 (je sais, les geeks ont des jeux bizarres…)

Fort de ma remise à niveau, il était temps de déployer IPv6 tout autour de ma sphère personnelle.

Un petit panaché donc des différents environnements et situations que j’ai rencontré et dont, je pense, l’un d’entre eux répondra à vos attentes.

RAPPEL DES FAITS

Non, je ne vous ferais pas un cours sur IPv6, mais il faut bien évidemment revoir nos classiques et surtout la façon dont fonctionne l’adressage IPv6.

Pour commencer, je vous invite a lire la page Wikipédia.

Maintenant, vous savez qu’une adresse IPv6 est longue de 128 bits contre 32 en IPv4.

De plus, l’écriture est au format hexadécimal et non décimal.

Pour résumer :

Mais s’il y a un « schéma » qui m’a permit de tout comprendre, c’est celui la :

2001:12d3:4:56 00: 0000:0000:0000:0000
\____________/ \_/ \..._/
partie réseau  s/s  partie pour l'identifiant
(56)           (8)    (64)

Si vous avez un /64, vous avec donc les 56 premiers bits+ les 8 bits de sous réseau + 64 bits pour vos machines (en gros cela nous fait 18 milliards de milliards d’adresses IP à votre disposition…)

Si vous avez un /56, vous avez donc les 56 premiers bits + 2^8 (256) sous réseaux X 2^64 adresses IP (18 446 744 073 709 551 616)…

Donc avec un /56 vous avec 256 sous-réseaux de 18 milliards de milliards d’adresses IP chacun… (un peu too much, non ?… )

Et bien sur, vous pouvez encore redécouper (/126, /120, /112 etc…).

Plus clair ?

ATTENTION : Une remarque importante, iptables ne contrôle pas les flux IPv6 sur vos interfaces. Il faut utiliser ip6tables pour protéger vos accès. N’oubliez donc pas de configurer en plus d’iptables, un ip6tables sur vos serveurs/pc… (et de, surtout, laisser l’icmp6 autorisé…)

CONNECTIVITE IPv6

Si vous êtes dégroupé chez Free (ou chez Nerim), vous avez la chance d’avoir un adressage IPv6 disponible rien que pour vous.

Malheureusement, étant non-dégroupé, je n’ai pas cette option, comme de nombreuses personnes chez d’autres FAI (quand je vous disais que vous avez de beaux jours en IPv4, les FAI ne sachant pas eux même faire fonctionner leurs architectures en IPv6 de bout en bout…).

La solution est le tunnel « 6to4″.

Un tunnel « 6to4″ permet de relier un réseau Ipv4 au réseau IPv6.

Les principaux fournisseurs de tunnels 6to4 sont :

-Hurricane Electric http://www.tunnelbroker.net

-Gogo6 (Freenet6) http://www.gogo6.com

-Sixxs http://www.sixxs.net

Je ne me lancerais pas dans un comparatif mais pour avoir utiliser les trois, j’ai un faible pour Gogo6 dont la facilité d’installation et la stabilité du tunnel m’ont bien plu.

Une fois enregistré chez eux, il en vous reste qu’a télécharger le source d’installation pour Linux (ou autre hein…) la : http://gogonet.gogo6.com/page/download-1

Compilation basique (make, make installdir=/usr/local/bin/gogoc install) et configuration des plus simples (userid, mot de passe et server=authenticated.freenet6.net bref lire le fichier de conf)

Il ne reste qu’a lancer l’executable (/usr/local/gogoc/bin/gogoc par exemple) pour voir un nouveau tunnel se monter dans vos interfaces réseaux :

tun       Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
adr inet6: 2001:5c0:1400:b::5b43/128 Scope:Global

et voila, vous avez un accès IPv6 :

server:/usr/local/gogoc/bin# ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8007::6a) 56 data bytes
64 bytes from 2a00:1450:8007::6a: icmp_seq=1 ttl=55 time=60.4 ms

simple non ?

Par votre navigateur Internet, a vous la joie de voir la tortue Kame gigoter pour prouver que vous utilisez une connexion IPv6.

SERVEURS DEDIES OVH

Ayant des serveurs chez OVH, ce dernier vous attribue une plage d’adresses IPv6 a utiliser sur votre serveur.

Pour cela rien de plus simple, se rendre dans son « Manager », sur la page « serveur dédié », et récupérer le /64 qui vous est attribué.

Le guide est dispo ici : http://guides.ovh.com/Ipv4Ipv6

Rien de bien compliquer mais personnellement, j’en voulais un peu plus et donc utiliser aussi l’IPv6 dans mes machines virtuelles VMWare…

La cela se complique un peu plus mais la réponse je l’ai trouvé sur le blog Linux Attitude, grâce à un excellent tuto écrit par StalkR.

En fait, OVH ne vous attribue pas un simple /64 mais un /56… Ce qui fait que vous pouvez subnetter vos adresses IPv6

Donc pour le /64 qui m’était par exemple attribué : 2001:12D3:4:5678::/64 j’ai donc à ma disposition le bloc suivant : 2001:12D3:4:5600::/56.

Ni une, ni deux, on se prend un petit subnet pour les VMs :

• 2001:12D3:4:5678::/64 pour les serveurs physiques
• 2001:12D3:4:5681::/64 pour les VMs.

(vous suivez toujours ? 2001:12D3:4:56.. est le bloc réseau que m’attribue OVH et j’ai pour moi 256 sous-réseaux (les 8 bits après le chiffre 56, pour créer mes subnets. Dans le cas présent …78.. et ..81.. (a vous de choisir dans la plage hexadecimal de 00 a FE).

A cet effet, une page web intéressante pour visualiser d’un coup tout cela : TABLE ASCII

Chaque sous-réseau disposant de 18 milliards de milliards d’adresses pour mes serveurs (honnêtement, je n’en ai pas autant…)

Un peu de tuning Kernel parce que je ne veux pas d’autoconfiguration.

Ah oui, j’ai oublié de vous parler de cela…

IPv6 a parmi ses facultés, celle d’autoconfigurer les interfaces réseaux et les routes dynamiquement grâce au « Router Advertisement« . En gros, cela permet a Mme Michu de ne pas se prendre la tête et d’avoir une configuration automatique (genre dhcp) annoncé par le routeur IPv6 en amont de sa connexion.

Je ne rentrerais pas dans le détail, (RADVD étant une excellente solution pour l’autoconfiguration de votre parc), car personnellement je tenais a maîtriser chaque étape de mon déploiement.

serveur:~# cat /etc/sysctl.conf
...
net.ipv6.conf.eth0.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.router_solicitations=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv6.conf.all.forwarding=1

Sur le serveur physique :

ip route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0 (1)
ip route add default via 2001:12d3:4:56ff:ff:ff:ff:ff (2)
ip route add 2001:12d3:4:5678::/64 dev vmnet1 (3)
ip neigh add proxy 2001:12d3:4:56ff:ff:ff:ff:ff dev vmnet1 (4)
ip neigh add proxy 2001:12d3:4:5681::1 dev eth0 (5)

A ajouter dans votre /etc/rc.local par exemple pour que cela soit effectif à chaque reboot (sans les (1),(2) etc..) )

Explication :

(1) J’ajoute la route vers la passerelle sur l’interface eth0

(2) J’ajoute la passerelle IPv6 comme route par défaut

(3) J’ajoute une route vers mon subnet /64 dédié a mes VMs sur l’interface VMware

(4) Je demande a l’interface vmnet1 de répondre aux requêtes à destination de l’ip de la passerelle

(5) Je demande a l’interface eth0 de répondre aux requêtes à destination de l’ipv6 de ma VM.

On attribue l’IPv6 2001:12d3:4:5681::1/64 dans notre VM.

# IPV6
iface eth0 inet6 static
address 2001:12D3:4:5681::1/64
netmask 64

On rajoute les routes dans /etc/rc.local

ip route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0
ip route add default via 2001:12d3:4:56ff:ff:ff:ff:ff

Pas la peine de toucher au kernel pour la VM.

On reboot tout le bouzin (physique et virtuel) et hop, magique, la VM est accessible en IPv6 de l’extérieur

SITE WEB

Les serveurs sont en IPv6, reste à rendre accessible votre site web.

Que votre serveur http soit Nginx, Apache ou autre, pas de grandes différences. (Attention, pour Nginx il faut compiler avec l’option –with-ipv6).

Juste se rappeler que les adresses IPv6 s’écrivent entre crochets.

On fait écouter le serveur sur l’IPv6 :

Listen [2001:41d0:2:67a::150]:80

Et on configure un vhost en conséquence :

NameVirtualHost [2001:41d0:2:67a::150]:80
 
...

Il ne vous reste plus qu’a ajouter une entrée de type AAAA dans votre DNS.

dig -t AAAA blog.guiguiabloc.fr
 
;; QUESTION SECTION:
;blog.guiguiabloc.fr.           IN      AAAA
 
;; ANSWER SECTION:
blog.guiguiabloc.fr.    86400   IN      AAAA    2001:41d0:2:67a::150

Et voila, le blog est accessible en IPv6 (j’ai même mis un joli logo en bas de la page ), et vérifié par ipv6forum.

IPv6 AVEC OPENVPN

Utilisant des tunnels openvpn entre mon domicile et mes serveurs OVH, bien entendu, l’idée de me servir du bloc d’adresses IPv6 d’OVH chez moi m’a tout de suite interpellé.

Comme pour les VMs, c’est assez triviale et plutot que de vous expliquez la procédure, je vous invite a lire les excellents tutos de GeekFault ou de  Vincent Riquer.

La seule différence notable est que j’utilise Vyatta comme client Openvpn chez moi (en tant que routeur d’interconnexion VPN).

Pour la spécificité Vyatta, j’ai modifié l’interface de cette façon :

openvpn-option « –dev-type tap –dev vtap0″

Ce qui me permet d’avoir une interface de type TAP et non TUN pour mon tunnel.

Vous pouvez ou utiliser RADVD comme décrit dans les tutos cités, ou utiliser le push ipv6 via le patch de Gert Döring , ou la même technique que pour les VMs.

CISCO et ADRESSAGE PRIVE IPv6

La on se spécifie un peu…

Si comme moi, vous avez monter un gros LAN des familles, l’idée d’utiliser des adresses IPv6 publiques vous enchantent moyennement.

Après tout, vous avez déjà un adressage privé IPv4, pourquoi ne pas continuer en IPv6.

Oyé, Oyé, l’adressage privé IPv6 existe.

Il a pour nom ULA (Unique Local Address) (a lire) et répond a la RFC 4193 (ex 3879).

Son plan d’adressage est le suivant : FC00::/7

( /7 ca fait un peu de monde… en fait /8 si l’on veut être propre)

Lire cet article également, et pour les connexions site à site et la technique pour générer des plans d’adressages ULA basés sur les MAC, lire : http://www.bortzmeyer.org/4193.html (ah ah ah, est-ce la fin des conflits des domaines d’encryption VPN (les habitués des tunnels ipsec comprendront…))

Bien, trêve de plaisanterie, passons a la pratique.

On se réserve un /48 pour la maison.

fd44:4ff0:adda::/48

Mise en place de la passerelle sur le routeur Cisco pour le vlan concerné :

Vlan concerné : 10

Adressage IPv6 : fd44:4ff0:adda:10::/64

cisco#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
cisco(config)#ipv6 unicast-routing
cisco(config)#int fa 0/0.10
cisco(config-subif)#ipv6 enable
cisco(config-subif)#ipv6 address FD44:4FF0:ADDA:10::1/64
cisco(config-subif)#
cisco#ping FD44:4FF0:ADDA:10::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD44:4FF0:ADDA:10::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

Sur un pc du vlan :

ifconfig eth0 inet6 add FD44:4FF0:ADDA:10::5/64
 
pc:# ping6 FD44:4FF0:ADDA:10::1
PING FD44:4FF0:ADDA:10::1(fd44:4ff0:adda:10::1) 56 data bytes
64 bytes from fd44:4ff0:adda:10::1: icmp_seq=1 ttl=64 time=1.09 ms
64 bytes from fd44:4ff0:adda:10::1: icmp_seq=2 ttl=64 time=1.10 ms

Et voila, rien de bien compliqué.

Si vous souhaitez ajouter une route statique ou par défaut, par exemple vers FD44:4FF0:ADDA:33::5

cisco(config)#ipv6 route ::/0 FD44:4FF0:ADDA:33::5

Pour vos ACL même genre (ipv6 access-list)

Un petit blog a lire avec quelques trucs et astuces Cisco et IPv6 : http://www.gho.no/tag/ipv6/

Vous pouvez donc déployer IPv6 dans votre LAN sans être routé sur Internet.

Bien évidemment, rien ne vous interdit d’utiliser les adresses IPv6 publiques dont vous disposez.

Voila pour une approche tout en douceur de l’IPv6, j’espère que ce billet vous a donner envie de manipuler un peu IPv6 et de vous préparer à la Fin du Monde

Amusez-vous bien

Suite à ce billet sur la mise en oeuvre de VMware Server 2 sur un serveur dédié OVH, il semble que certain d’entre vous soit en difficulté pour affecter une ip failover à votre Machine Virtuelle et pour la faire communiquer avec le Nain Ternet.

Donc , petite mise au point et tuto pour le « comment qu’on fait » pour mettre une ip failover OVH sur ma VM.

• Pré-requis Hôte
  

Vous avez lu le billet sur l’installation VMWare et l’hôte est opérationnel.

J’appelerais l’hôte le serveur sur lequel est installé VMWare server.

L’interface Host-only utilisée sur l’hôte est VMNET1 :

hote# ifconfig
 
vmnet1    Lien encap:Ethernet  HWaddr 00:50:56:C0:00:01
          inet adr:10.154.98.1  Bcast:10.154.98.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3675317 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3013354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

L’ip affectée à VMNET1 est de classe privée (192.168/16, 172.16/12 ou 10/8) ici, 10.154.98.1/24 (la notation /24 correspond au nombre de bits du masque se sous-réseau donc ici 255.255.255.0).

Le forwarding IP est activée :

hote# cat /proc/sys/net/ipv4/ip_forward
1

Le proxy ARP est actif sur l’interface VMNET1 :

hote# cat /proc/sys/net/ipv4/conf/vmnet1/proxy_arp
1

Si les valeurs sont a 0, les activer :

hote# /bin/echo "1" > /proc/sys/net/ipv4/ip_forward
hote# /bin/echo "1" > /proc/sys/net/ipv4/conf/vmnet1/proxy_arp

L’ip FailOver utilisée dans cette exemple est 91.121.58.158.

On ajoute une route par défaut pour l’ipFailover :

hote# route add 91.121.58.158 dev vmnet1
hote# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
91.121.58.158  0.0.0.0         255.255.255.255 UH    0      0        0 vmnet1

• Machine Virtuelle Linux (type Debian)

guest:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
 
# The loopback network interface
auto lo
iface lo inet loopback
 
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 91.121.58.158
netmask 255.255.255.255
dns-nameservers 213.186.33.99
 
post-up /sbin/route add default dev eth0

N’oubliez pas de renseigner vos serveurs de noms (opendns ici)

guest:~# cat /etc/resolv.conf
search localdomain
nameserver 208.67.222.222
nameserver 208.67.220.220

On reboot, Un ping sur une adresse externe doit fonctionner sans problème :

LinuxVM

Si vous préférez faire la config à la main :

guest# ifconfig eth0 91.121.58.158 netmask 255.255.255.255
guest# route add default dev eth0

• Machine Virtuelle WINDOWS

Etape 1

On spécifie l’ip failover, la passerelle qui l’adresse de VMNET1 de l’hôte et les DNS.

Concernant les masques, si vous laissez 255.255.255.255, vous aurez un message d’erreur :

Erreur masque

On va donc laisser 255.255.255.0 pour l’instant :

Masque par defaut

Lancer Regedit pour modifier la valeur du netmask (Démarrer/executer/Regedit).

Déplacer vous sur HkEY_LOCAL_MACHINE/SYSTEM et faites une recherche sur « subnet »

Modification dans le registre

Modifie la valeur 255.255.255.0 en 255.255.255.255

Modification Netmask

On reboot le pc, tout doit être ok désormais :

Test final

ATTENTION le netmask affichée est INCORRECT !! LA PREUVE :

Bug netmask ipconfig

En espèrant que cela vous aide

Dans la continuité de la découverte des petites spécificités de la plateforme d’hébergement dédié d’OVH, aujourd’hui l’installation de VMWare Server 2.0.

Nous allons tout d’abord voir son installation en tenant compte des particularités d’OVH, l’utilisation de l’IpFailover et/ou des blocs ip RIPE fournis avec les serveurs et pour finir, en bonus, une petite bidouille à la Guiguiabloc pour intégrer un datastore VMWare en Raid1 over ip et bascule automatique.

Bien entendu, je pars d’une distribution Linux de base (Debian Etch ici) et pas la distribution VMware que fourni OVH.

Pré-Requis : Vous avez lu CE PRECEDENT BILLET avant et donc vous avez recompilé votre noyau sur vos serveurs. (il vous faut les sources du kernel).

Les switchs OVH ont une sécurité sur leurs interfaces empêchant de faire du bridging sur l’interface eth0 de votre serveur (ce qui est très bien en soi).

En gros, vous ne pouvez pas sortir sur l’interface du switch avec une adresse MAC différente de celle de votre carte réseau, si vous brigder l’interface vmnet0 avec eth0, le switch se mettra en « défense » (scénario bien connu des bidouilleurs de Cisco ) et vous coupera le port.

A savoir que le principe est le même avec XEN donc attention a ce que vous faites…

Nous allons donc bridger VMware sur une interface bidon et configurer le Host-Only pour les interfaces réseaux de nos Machines Virtuelles.

On commence par monter une fausse interface ethernet, en éditant notre fichier /etc/network/interfaces (Debian) :

auto dummy0
iface dummy0 inet static
address 10.0.0.1 netmask 255.0.0.0 [ATTENTION CHOISIR UNE IP DE CLASSE PRIVEE]

Puis on l’active : ifup dummy0

(on vérifier par ifconfig que cette interface est bien présente).

On peut attaquer l’installation de VMware Server (je vous passe la phase de vous rendre sur le site de VMware pour récuperer le package et le numéro de série gratuit…)

tar xzvf VMware-server-2.0.0-116503.i386.tar.gz

cd vmware-server-distrib/

./vmware-install.pl
Creating a new VMware Server installer database using the tar4 format.

Installing VMware Server.

Vous répondez aux questions qui s’affichent (en changeant selon vos désirs les réponses pré-définies)

Si tout ce passe bien, vous devriez arrivé ici :

The installation of VMware Server 2.0.0 build-116503 for Linux completed
successfully. You can decide to remove this software from your system at any
time by invoking the following command: « /usr/bin/vmware-uninstall.pl ».

Before running VMware Server for the first time, you need to configure it by
invoking the following command: « /usr/bin/vmware-config.pl ». Do you want this
program to invoke the command for you now? [yes]

Vous suivez la procédure jusqu’au paramétrage du réseau :

La, on devient un peu plus attentif

Do you want networking for your virtual machines? (yes/no/help) [yes]

Configuring a bridged network for vmnet0.

Please specify a name for this network.
[Bridged]

Your computer has multiple ethernet network interfaces available: dummy0, eth0 . Which one do you want to bridge to
vmnet0? [eth0] dummy0

The following bridged networks have been defined:

. vmnet0 is bridged to dummy0

Do you wish to configure another bridged network? (yes/no) [no] no

Do you want to be able to use NAT networking in your virtual machines? (yes/no)
[yes] no

Do you want to be able to use host-only networking in your virtual machines?
[no] yes

Configuring a host-only network for vmnet1.

Please specify a name for this network.
[HostOnly]

Do you want this program to probe for an unused private subnet? (yes/no/help)
[yes] no

What will be the IP address of your host on the private
network? 192.168.1.1 [ATTENTION CHOISIR UNE IP DE CLASSE PRIVEE]

What will be the netmask of your private network? 255.255.255.0
the following host-only networks have been defined:

. vmnet1 is a host-only network on private subnet 192.168.0.

Do you wish to configure another host-only network? (yes/no) [no] (vous pouvez créer d’autres interfaces si vous le souhaitez)

None of the pre-built vmnet modules for VMware Server is suitable for your
running kernel. Do you want this program to try to build the vmnet module for
your system (you need to have a C compiler installed on your system)? [yes]

Extracting the sources of the vmnet module.

Building the vmnet module etc..

The configuration of VMware Server 2.0.0 build-116503 for Linux for this
running kernel completed successfully.

Et voila, vous pouvez faire pareil sur l’autre serveur (si vous en avez deux )

Vous pouvez vous connecter sur l’excellente interface d’administration : https://votrededieovh:8333

Lancer la création et l’installation d’une nouvelle machine virtuelle en donnant comme interface réseau, l’interface Host-only VMNET1.

(je ne parle pas du fonctionnement de VMware server ici, Google vous rapportera pleins de tutos )

• Configuration du réseau

On commence par activiter le forwarding entre vos cartes réseaux (en l’occurence etho et vmnet1 ici) :

/bin/echo « 1″ > /proc/sys/net/ipv4/ip_forward

(n’oublier pas de le mettre en dur dans votre /etc/sysctl.conf : sysctl net.ipv4.ip_forward=1)

Puis le proxy ARP :

echo "net.ipv4.conf.vmnet1.proxy_arp=1" >> /etc/sysctl.conf && sysctl -p

Sur la machine virtuelle, on configure notre ipfailover et/ou notre ip bloc RIPE :
/etc/network/interfaces :

iface eth0 inet static
address 91.x.x.x
netmask 255.255.255.240
broadcast 91.x.x.x
post-up /sbin/route add default dev eth0
Pour une IP bloc RIPE (voir les infos que vous donne OVH pour le netmask et le broadcast lorsque vous commander votre bloc ip ou utiliser l’excellent « sipcalc » pour calculer vos masques/reseau )

Pour un ipfailover (a adapter a votre ipfailover):

auto eth0
iface eth0 inet static
address 87.98.99.90
netmask 255.255.255.255
post-up /sbin/route add default dev eth0

La commande importante étant de lui spécifier eth0 comme passerelle par défaut ( /sbin/route add default dev eth0).

Sur votre dédié maintenant (le serveur VMware), il faut lui donner la route vers votre machine virtuelle :

/sbin/ip route add 87.88.89.90 dev vmnet1

Pour le rendre permanent, vous pouvez rajouter la commande dans /etc/init.d/vmware apres le chargement des modules réseaux ou vous basez sur la bidouille de Kro : http://forum.ovh.com/showthread.php?t=37645

(attention a adapter hein !!!).

EDIT : Pour l’explication détaillée pour VMWare Server 2.0, le billet de Superkikim ICI vous donnera toute satisafaction.

Voila, vous pouvez désormais pinguer le net depuis votre machine virtuelle et inversement.

(ne pas oublier le /etc/resolv.conf et tutti quanti…)

EDIT 2 : J’ai écris un billet sur la façon d’affecter une ip failover à votre VM, c’est ICI.

• Bidouille Guiguiabloc

Bon maintenant que tout cela tourne très bien, le plus « amusant » serait de pouvoir basculer notre machine virtuelle sur notre deuxième serveur en cas de crash du premier…

Je vous préviens tout de suite, cela ne sera pas transparent VMotion n’existe pas sur VMware server

Pré-requis : la lecture du précédent billet :-p (encore), un drbd actif, un heartbeat actif et une ipfailover disponible.

On se créer un volume DRBD (j’espère que vous avez prévu un stock de partitions de libre lors de l’installation de votre dédié OVH )

en éditant notre fichier /etc/drbd.conf et on ajoute :

resource r1 { (ou r0 si c’est votre premiere ressource drbd)
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 »;

}

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

disk {
on-io-error detach;

}

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

syncer {
rate 20M;
al-extents 257;
}
on ns11111 {
device /dev/drbd1;
disk /dev/sda11;
address 192.168.20.20:7789; (attention a ne pas mettre le meme port de la ressource r0)
meta-disk internal;
}

on ns22222 {
device /dev/drbd1;
disk /dev/sda11;
address 192.168.20.30:7789;
meta-disk internal;
}
}

On se coltine les définitions Maitre/Esclave (voir billet précédent), on formate /dev/drbd1.

Sur le serveur ns11111, on monte /dev/drdb1 sur /vmfs (par exemple) et on l’ajoute au datastore :

Vous devriez voir votre datastore apparaitre dans la liste :

Créer une machine virtuelle dedans ou comme moi, copier le repertoire de votre Machine Virtuelle et utilisez le « Add to Inventory » :

On stoppe VMware, on démonte /vmfs et on inverse les roles Maitre esclave :

sur ns11111 : drbdadm secondary r1

sur ns22222: drbdadm primary r1

on vérifie que l’on voit bien tout avec un cat /proc/drbd puis on monte /dev/drbd1 sur /vmfs.

Sur le VMware server de ns22222, on refait la meme manip, déclaration d’un nouveau datastore et « AddVirtual Machine to Inventory ».

• premier test

On se remet en environnement nomimal (vmware qui tourne sur ns11111, drbd1 en maitre et mount sur /vmfs)

On lance la VM sur ns11111.

On vérifie que tout marche bien et maintenant, simulons le crash manuellement.

- on kill -9 tout les process VMware (oui c’est crade, j’adore )

- on démonte /vmfs

- on bascule les ressources DrBD

- on lance vmware sur ns22222

- on lance la machine virtuelle.

Les soucis rencontrés sont les suivants :

L’uid disque a changer et il faut cliquer sur « i ‘ve copied it »

Ca c’est facile a régler, vous ajouter

uuid.action = "keep"

Dans le fichier *.vmx de votre machine virtuelle

Un répertoire « lock » verrouille le démarrage.

Il suffit de faire un petit rm -rf Guiguiabloc.vmdk.lck pour que ca parte.

Donc cela marche, mais il faut automatiser tout cela.

Heureusement, il existe les commandes vmrun.

La syntaxe est la suivante :

vmrun -T server -h https://localhost:8333/sdk -u adminvmware -p motdepasse stop « [VMFS-DRBD] Guiguiabloc/Guiguiabloc.vmx »

Pour arreter la VM par exemple (je vous laisse consulter la doc VMRUN sur le site de VMware ).

Vous avez donc tout les éléments pour inclure cela dans les scripts de Heartbeat (basez vous sur les exemples du précédent billet) :

1. bascule du DRBD et montage sur /vmfs
2. Démarrage de VMware sur le nouveau Maître
3. rm -r /vmfs/machinevirtuelle/machinevirtuellevmdk.lck
4. vmrun start

Tout bête quoi

Après plusieurs tests cela marche vraiment pas mal , bien évidemment le crash du maitre entraîne le « crash » de la VM, donc elle peut repartir un peu en vrac.

C’est pour cela que je vous conseille de programmer des « Snapshots » des VM toutes les nuits (si vous ne connaissez pas, jetez vous dessus et mangez en !!! )

Au pire vous pourrez repartir sur le snapshot de la veille.

En tout cas, avec cela l’indisponibilité est de quelques minutes…