Failover IP sur une VM en proxy-arp

Le proxy-arp est une technique intéressante qui permet de se passer d'un bridge lorsqu'on héberge des machines virtuelles. Elle empêche également l'admin de la VM de voler des addresses dans le subnet local comme c'est le cas avec un bridge. Cepandant, attention à cette intéraction néfaste avec le failover IP...

Avec une VM bridgée classique, l'hôte établit un pont entre l'interface réseau physique et les interfaces réseau virtuelles. Les requêtes ARP sur le subnet local sont transmises à toutes les VM, et chaque VM décide ou non d'y répondre, sans contrôle de l'hôte (bien sur on peut utiliser ebtables pour filtrer)

Au lieu d'utiliser des interfaces virtuelles de type ethernet, on peut également utiliser des liens point-à-point virtuels. Côté VM, l'interface a donc une addresse unique /32, et une addresse p2p fixe (typiquement 10.64.64.64) qui sert de passerelle par défaut. Côté hôte, pas de problème pour avoir une addresse unique sur plusieurs interfaces, parce que les interfaces sont point-à-point, il n'y a donc pas d'ambiguité sur la source. Mais dans cette configuration, comment le routeur du subnet local sait-il qu'il doit addresser les paquets a destination des VM sur l'addresse de l'hôte ?

En activant le proxy-arp sur l'interface physique de l'hôte, l'hôte répondra en arp pour toutes les addresses qu'il est capable de router. Il suffit donc d'ajouter une route statique vers le bon tunnel point-a-point pour chaque VM. C'est ce que fait, d'ailleurs, le script fourni avec openvz pour la gestion des addresses des VMs.

Mais que se passe-il si, par mégarde, une VM vient a déconfigurer une addresse qui lui a été allouée, sans en avertir l'hôte ?

La route statique étant en place, l'hôte va continuer a router les paquets à destination de cette addresse vers le tunnel. Et si le guest a le forwarding activé, il va joyeusement transmettre les même paquets à sa passerelle par défaut, dans le même tunnel, dans l'autre sens.

Chez moi, ça se traduit par un load average de 12, ksoftirqd qui prend 60% du cpu, et 5 secondes de latence entre chaque caractère tapé en ssh.

En bridge, ça marche mieux...

Tutorial: un VPN ipv6 pour la maison, sous Gentoo

Voici comment se fournir un bloc IPv6 statique a domicile, a partir d'un serveur ayant une addresse v4 stable, avec 6to4 et OpenVPN.

Mes machines, toutes deux sous Gentoo:
* Xolus: serveur housé avec une IP statique sur eth0
* Glokrik: serveur de la maison, IP NAT sur eth0

6to4

La configuration de 6to4 est facile avec Gentoo. J'ajoute dans /etc/conf.d/net sur xolus:


link_6to4="eth0"
config_6to4="ip6to4"
depend_6to4() { need net.eth0 }


Et je crée le service correspondant:


ln -s net.lo /etc/init.d/net.6to4
rc-update add net.6to4 default
rc


Et on teste:


ping6 www.kame.net


OpenVPN

On emerge openvpn sur les deux machines, et on commence par créer les clefs cryptographiques nécessaires. Pour deux machines les clefs statiques sont plus simples, mais dans l'hypothèse d'un ajout ultérieur de machines je vais utiliser une PKI. Il y a des scripts d'aide dans /usr/share/openssl/easy-rsa/. On copie ce répertoire vers un rep de travail.

On y édite le fichier vars et on ajuste les champs des dernières lignes. Puis on source ce fichier et on génère la CA et les clefs des serveurs:


. ./vars
./clean-all
./build-ca
./build-key-server xolus
./build-key glokrik
./build-dh


On viole techniquement un principe des PKI en générant les clefs client sur le serveur, mais bon ;)

Sur xolus, je copie ca.crt, dh1024.pem, xolus.crt et xolus.key dans /etc/openvpn/. Je transfère ensuite ca.crt, glokrik.key et glokrik.pem au meme endroit sur la machine glokrik.

Sur xolus, je crée la définition suivante dans /etc/openvpn/openvpn.conf:


port 1194
proto udp
dev openvpn
dev-type tun
tun-ipv6
tls-server
ca ca.crt
cert xolus.crt
key xolus.key
dh dh1024.pem


Sur glokrik, dans /etc/openvpn/xolus.conf:


port 1194
proto udp
remote 213.162.22.228
dev xolus
dev-type tun
tun-ipv6
tls-client
ca ca.crt
cert glokrik.crt
key glokrik.key


On ajoute les services openvpn au démarrage. Les machines disposent maintenant chacune d'une interface réseau tunnel supplémentaire, qu'il faut maintenant configurer

On vérifie sur les deux machines, avec ip link show, que les deux interfaces sont actives (flag LOWER_UP).

Tunnel IPv6

On commence par calculer le bloc 6to4 à disposition. L'IP fixe de ma machine est 213.162.22.228, mon bloc 6to4 est donc 2002:d5a2:16e4::/48. (Prefixe 2002, suivi de l'addresse v4 convertie en hexadécimal). Il y a ensuite 16 bits disponibles pour le subnet, je vais utiliser 00ff pour le VPN, et 0001 pour le subnet de ma maison. Dans le subnet vpn, l'addresse ::ff sera attribuée au serveur, et l'addresse ::xxxx au client responsable du subnet xxxx.

Sur xolus, dans /etc/conf.d/net:


config_openvpn=( "2002:d5a2:16e4:ff::ff/64" )
routes_openvpn=( "2002:d5a2:16e4:1::/64 via 2002:d5a2:16e4:ff::1" )
depend_openvpn() {
need openvpn
}


Sur glokrik:


config_xolus=( "2002:d5a2:16e4:ff::1/64" )
routes_xolus=( "2000::/3 via 2002:d5a2:16e4:ff::ff" )
depend_xolus() {
need openvpn.xolus
}


On ajoute ces deux services au démarrage, on les lance, et on teste le fonctionnement du tunnel:


glokrik # ping6 2002:d5a2:16e4:ff::ff
PING gw.vpn.xolus.net(2002:d5a2:16e4:ff::ff) 56 data bytes
64 bytes from 2002:d5a2:16e4:ff::ff: icmpseq=1 ttl=64 time=8.54 ms
64 bytes from 2002:d5a2:16e4:ff::ff: icmpseq=2 ttl=64 time=8.11 ms


On active ensuite le forwarding sur la passerelle:


echo "net.ipv6.conf.all.forwarding = 1" >>/etc/sysctl.conf
sysctl -p


Glokrik peut maintenant pinguer des sites ipv6 publics:


glokrik # ping6 www.kame.net
PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=58 time=340 ms


RADVD

Il faut maintenant fournir la connectivité ipv6 aux hôtes de la maison. Pour celà il suffit d'installer radvd sur glokrik, et d'y ajouter la conf qui va bien dans /etc/radvd.conf_


interface eth0 {
AdvSendAdvert on;
prefix 2002:d5a2:16e4:1::1/64 {
AdvOnLink on;
AdvAutonomous on;
};
};


On édite ensuite le script de démarrage /etc/init.d/radvd pour changer la dépendance:


depend() {
need net.xolus
}


Ce qui empêche radvd de démarrer tant que le lien vpn n'est pas up.

Notez qu'il n'y a pas besoin d'activer le forwarding ipv6 sur glokrik, le script de démarrage de radvd s'en charge.

radvd démarré, ma machine de bureau reçoit presque immédiatement une addrese v6, et je peux pinguer des sites publics.

6to4reverse

Une fois la connexion 6to4 active, il suffit d'aller sur https://6to4.nro.net et d'enregistrer ses serveurs de noms pour disposer du reverse.

Une conférence avec Michel Riguidel

  J'ai eu le plaisir, cet après-midi, d'assister à une conférence ayant pour thème les dangers et futurs enjeux de la guerre électronique. Parmi les invités, un certain Michel Riguidel, dont le nom m'est alors inconnu, cité comme "conseiller pour le gouvernement français" en matière de cybersécurité, et auteur de plusieurs  brevets liés a la sécurité.

  Dès la première slide, bien remplie de texte, on comprend que la présentation sera technique et concrète, loin des généralités banales du conférencier précédent. Je m'en réjouis.

 Pas pour longtemps, hélas.

  Je vais immédiatement mentionner le SEUL point de son discours avec lequel je me trouve en accord: les géants comme Facebook présentent un danger significatif pour la vie privée (pour M. Riguidel, un tel pouvoir est une prérogative d'état.)

M. Rigidel accumule dans son discours tellement de "WTF"s et d'apparentes inepties que je n'ai la présence d'esprit de tous les noter. Ce dont je me rappelle, en vrac:

- TCP/IP est complètement obsolète (je suis d'accord pour TCP, mais avec LTE et les futurs réseaux téléphoniques tout IP, on peut se poser la question)
 - la liberté sur Internet conduira au nivellement par le bas de la culture (LOL)
 - PGP est une catastrope politique (LOL)
 - Le chiffrement ne sert qu'aux entreprises désirant narguer le gouvernement en l'empêchant de surveiller ses flux (parce que le gouvernement est incapable d'obtenir une clef de chiffrement par des moyens non-techniques, le citoyen doit renoncer au chiffrement même si cela l'expose aux abus de son ISP ou d'un fournisseur de cloud)
 - Cloud et P2P sont des technologies opposées, et populairs par effet de mode mais de nature éphémère.
 - L'anonymat sur internet est une catastrophe, des personnalités (dont lui-même) se font diffamer sans aucun contrôle (Effet Streisand, il ne connaît pas ?)
 - Les "hippies" soutenant le libre sont une minorité de hackers marginaux dont le travail n'est bénéfique que très occasionnellement (il ne doit pas être au courant de la représentation de Linux dans le top500, tiens).
 - Internet est tellement centralisé qu'il se résume aujourd'hui a 300 serveurs
 - Puisque la loi de Moore s'est arrêtée en 2008, et comme il est impossible de scaler un système a plus de 4 processeurs, l'arrêt brutal de la performance amènera un "crépuscule numérique". (Larrabee ça n'existe pas)
 - L'informatique sera obsolète en 2100 et remplacée par la nanotechnologie.
 - Le progrès cryptographique en occident est arrêté depuis 10 ans et les chinois sont largement en avance sur l'europe ou les états-unis.

  Ces positions déraisonnables relèvent au mieux de l'incompétence, au pire d'une totale malhonnêteté intellectuelle. Je me demande si M. Riguidel croit vraiment à ce qu'il raconte, ou s'il déforme volontairement la réalité pour pousser un agenda politique.

  Pour le dernier point de la liste, je me suis fendu d'une question simple: pourquoi, si la chine est tellement en avance en matière de crypto, les universités chinoises représentent moins de 20% des publications soumises à Asiacrypt 2011 ? réponse de M. Riguidel: "ah mais dans ces conférences le jury est pipé de toute façon." Ben voyons. Et d'étayer son raisonnement par le fait que Xiaoyun Wang, d'origine chinoise, est l'auteure de plusieurs papiers sur des collisions de hachage. Je n'ai pas eu le coeur de lui rappeler qui est a l'origine des collisions sur certificats x509, ou de la factorisation de RSA-768, ou des milliers d'autres problèmes actuels en crypto. Mais bon.

  J'ai pu ainsi me faire, par moi-même, une opinion assez claire du personnage. Mais je suis quand meme allé voir sur google, histoire de voir de quelle "diffamation" il parlait. Je constate que S. Bortzmeyer, personnage avec qui j'ai eu le plaisir de discuter occasionnellement sur IRC, et dont je respecte hautement les compétences techniques, le qualifie ni plus ni moins de "Bogdanoff du net". Même son de cloche auprès de mes autres connaissances au sein du FrNOG.

  Je suis ébahi que l'UNIL offre une telle tribune à ce personnage, qui se permet de prendre position avec une arrogance incroyable sur des sujets sur lesquels le consensus est quasi universel au sein de la communauté scientifique, et sans offrir aucune démonstration ou justification à ses propos. Ebahi et un peu dégoûté.

  Dieu merci, les intervenants qui lui ont succédé ont fait preuve de raison et de pragmatisme, sans quoi je serais certainement parti avant la fin.

Tuning NFS pour démarrer un cluster

  Le cluster AMD64 du LACAL comporte 90 noeuds, pour l'instant tous servis depuis un frontend unique qui héberge leurs racines NFS. En cas de coupure, si tous les noeuds redémarrent en même temps, le serveur NFS se retrouve légèrement surchargé, et plusieurs noeuds se retrouvent dans un état bloqué (kernel panic).

  Une partie des noeuds ne dispose ni de contrôleur IPMI ni de watchdog, ce qui rend les redémarrages un peu chaotiques. Mais la situation peut être grandement améliorée par trois règlages:

1) Augmenter le nombre de processus pour le démon nfsd. Avec Gentoo ceci se règle par la variable OPTS_RPC_NFSD dans /etc/conf.d/nfsd

2) Utiliser le port 627 pour le démon mountd (même fichier, variable OPTS_RPC_MOUNTD). C'est le port spécifié n dur dans le noyau au cas ou le portmapper serait trop lent a répondre.

3) Augmenter la tolérance du client nfs, en passant l'option adéquate au noyau. Ici, dans la config pxelinux de chaque machine:

  append root=/dev/nfs nfsroot=10.1.0.2:/var/nfs/nodexx,retrans=10,timeo=30