Une ligne SIP permet d’avoir un numéro de téléphone fixe mais mobile. Pas mobile au sens d’un téléphone portable bien évidemment mais mobile au sens que je n’ai pas besoin de faire un courrier ou d’appeller un opérateur pour pouvoir utiliser ce numéro de téléphone ailleurs pour peu qu’il y ait une connexion Internet.

Mon choix s’est assez naturellement porté vers OVH étant donné la bonne expérience que j’ai pu avoir d’eux sur d’autres offres. J’avoues ne pas avoir comparé avec d’autres fournisseurs.

Au niveau tarification, la ligne ne coûte pratiquement rien soit 1,18€ TTC. Elle inclut un numéro de téléphone dans la zone de votre choix et les appels illimités vers les fixes de 40 pays. Il est également possible de souscrire à des options vers les téléphones mobiles. Le téléphone est « prêté » sous caution. Étant donné que la caution est égale au prix du téléphone, il aurait été probablement plus simple pour OVH de le vendre. L’intérêt de le prendre avec OVH est que les frais de port sont inclus et que le téléphone est auto-configuré (ou du moins censé l’être).

Lorsque vous commandez votre ligne SIP, vous effectuez le parcours classique de commande OVH sauf que là, il est nécessaire d’envoyer un courrier. Hé oui, envoyer du papier dans une enveloppe avec un timbre qu’il faut aller acheter à la Poste. En effet, il faut envoyer un chèque barré, une copie de carte d’identité et une autorisation de prélèvement. Du coup, vu que la Poste est passé en 48h au lieu de 24h pour le courrier classique, cela rajoute 2 jours de délai à l’obtention effective de la ligne. Ca reste assez raisonnable mais inhabituel pour OVH. On mettra tout cela sous le coup de la réglementation liée aux lignes téléphoniques.

Une fois le courrier réceptionné par OVH, vous recevrez très rapidement un mail contenant les identifiants pour vous connecter à votre compte SIP. Ceux que j’ai reçu pour ma ligne étaient erronés et j’ai donc dû les modifier dans le Manager OVH. Pour tester votre ligne sur votre Mac, je vous conseille Zoiper. La qualité et la latence n’est pas nécessairement exceptionnelle avec un softphone donc attendez de voir avec votre téléphone physique pour juger.

Si vous avez de la chance, vous recevrez votre téléphone le lendemain de l’activation de votre ligne SIP ce qui a été mon cas. OVH expédiant les téléphones via DHL, c’est rapide ! Vous pourrez ainsi déballer votre téléphone et le brancher directement dans votre box.

La configuration est sensé être automatique néanmoins dans mon cas, cela n’a pas été le cas. J’ai dû modifier le mot de passe dans l’interface de configuration web du téléphone. Cela est probablement lié au fait que le mot de passe fourni dans le mail par OVH était erroné. Une fois ce problème résolu, tout fonctionne parfaitement. La qualité sonore est tout à fait correcte et la latence acceptable. Cette dernière est, je pense, légèrement plus élevée que dans le cas de la téléphonie classique mais ca reste assez acceptable. Ce sera néanmoins à tester à partir d’un autre pays.

Sur son interface Manager dédiée à la téléphonie, OVH vous donne accès aux logs relatives à votre ligne ce qui vous permet de comprendre une éventuelle erreur de connexion et à de nombreuses options. L’offre par défaut à 1,18€ TTC ne propose que très peu d’options mais à ce prix là difficile de se plaindre.

Au final, l’offre d’OVH est vraiment très accessible au niveau tarif. La mise en place se fait bien malgré le fait qu’il faille envoyer un courrier papier via le « snail mail ». Il est néanmoins préférable de prendre un téléphone physique car la qualité et la latence est meilleure qu’avec un softphone de ce que j’ai pu tester.

Rappels

Historiquement, les proxy HTTP ont été mis en place afin d’accélérer les chargements des pages web. A une certaine époque l’acronyme WWW pouvait avoir pour signification « World Wide Wait ». La solution apportée à ce problème a été de mettre en cache les contenus au plus proche de l’utilisateur par le biais de proxy.

La gestion du cache HTTP doit être géré du coté du fournisseur de contenu, à savoir le serveur web. En théorie, ce dernier a autorité sur les données du site qui pourront être mises en cache ou non. Ces informations sont transmises dans les en-têtes HTTP par le biais de divers champs que nous ne détaillerons pas tous ici. Un champ particulièrement intéressant est la durée de rétention dans le cache.

Par défaut, Apache n’envoie pas d’informations quant à la mise en cache du contenu ce qui signifie donc qu’en théorie les données de notre site ne seront pas mises en cache. Dans notre situation, cela signifie que Squid ne met rien en cache tant que nous n’avons pas configuré Apache pour lui indiquer qu’il est possible de le faire.

Configuration d’Apache

Nous allons donc devoir paramétrer Apache pour utiliser les en-têtes contrôlant la mise en cache de nos pages web. Ainsi, notre serveur Squid pourra prendre une partie de la charge de notre serveur web et ainsi le soulager.

Le module Apache qui nous intéresse plus particulièrement est mod_expires. Son activation est simple et, dans le cas de Debian, il est packagé avec Apache. Il suffit donc de l’activer comme suit.

# a2enmod expires

# /etc/init.d/apache2 restart

Une fois ce module activé, nous allons pouvoir le configurer.

Configuration de mod _expires

Nous allons pouvoir configurer mod_expires par le biais de fichiers .htaccess comme il est possible de le faire pour bon nombre d’autres modules. Ce module nous permet de gérer assez finement la mise en cache des fichiers. La syntaxe est simpliste mais efficace. Si vous souhaitez obtenir une explication exhaustive dans la syntaxe et de ses fonctionnalités, je vous recommande de consulter la documentation.

Pour ce site, j’ai choisi la politique suivante de mise en cache.

ExpiresActive On
ExpiresByType image/gif « access plus 1 week »
ExpiresByType image/jpeg « access plus 1 week »
ExpiresByType image/png « access plus 1 week »
ExpiresByType text/css « access plus 1 days »
ExpiresByType application/x-shockwave-flash « access plus 1 hour »

Ensuite, c’est à vous de voir ce que vous voulez que Squid mette en cache ou pas en fonction des fonctionnalités de votre site.

Vérification

Afin de vérifier si tout fonctionne correctement, je vous invite à consulter les log d’accès à votre serveur Squid. Des lignes comportant « TCP_HIT » s’afficheront lorsque Squid servira des données du cache à la place d’Apache. Si vous n’avez que des « TCP_MISS », il doit probablement manquer un élément à votre configuration.

Au final, cette méthode permet d’accélérer significativement son site web et ainsi d’améliorer son référencement sur Google. Dans mon cas, le temps de chargement de ce site a été divisé par un facteur 2 à 3 ce qui est tout de même très intéressant. Des lecteurs m’ont fait remarquer qu’il existait une alternative plus moderne à Squid, Varnish qui permettrait de définir des politiques de mise en cache plus fine. Je vous laisse donc y jeter un coup d’œil !

Contexte

L’affichage de ce blog était relativement lent. Il pouvait mettre plus de 5 secondes pour s’afficher complètement ce qui n’est pas un temps d’affichage très bon. J’ai donc entrepris de trouver une solution à ce problème.

Ce site est hébergé sur une machine virtuelle Xen dont le système d’exploitation est OpenSolaris 2009.06. Elle est globalement assez lente car relativement peu de mémoire lui est alloué. De plus, la cohabitation d’Apache et de MySQL sur le même système ne favorise clairement pas les choses. Certains médisants diront que WordPress et/ou PHP sont des facteurs de lenteur. Ils auront raison mais je n’ai aucune intention d’utiliser autre chose que WordPress car c’est un réel plaisir à l’utiliser.

Un peu de théorie

Un proxy ou en Français « serveur mandataire » est un serveur qui se place entre le client et le serveur. Le client va interroger le proxy qui va à son tour interroger le serveur. Le serveur répondra au proxy qui, à son tour, répondra au client. Ceci est le fonctionnement le plus classique mais on peut placer un proxy dans nombreuses configurations et donner au proxy une intelligence supplémentaire.

Dans le cas de proxys HTTP(S) classiques, on y ajoute des mécanismes de cache afin d’économiser de la bande passante. On peut également y ajouter des fonctions de filtrage d’URL afin d’éviter la consultation de certains sites.

L’exemple d’application du proxy qui nous intéresse ici est le reverse proxy. Le client n’aura aucune connaissance de la présence d’un proxy et pensera qu’il s’agit d’un serveur HTTP comme un autre. Le proxy interrogera ensuite le serveur web et la requête sera renvoyée au client. Dans cette situation, la fonctionnalité de cache du proxy est très intéressante car elle permet d’éviter le traitement de certaines requêtes au serveur HTTP. On pourrait également utiliser le proxy couplé à plusieurs serveurs HTTP afin d’effectuer du load balancing et de la redondance.

Une autre VM

La première étape a été de trouver une machine supplémentaire afin de ne pas faire cohabiter la pile LAMP et Squid sur le même serveur. Dans l’absolu, ce n’est pas impossible mais lorsqu’on a un serveur déjà surchargé, ce n’est peut être pas la meilleure idée.

Étant donné qu’OVH vient de lancer son offre miniCloud, ce projet était une parfaite excuse pour la tester. Le prix de cette offre est vraiment très bas. Pour une VM de 256Mo de RAM, cela revient à 8,5€/mois. J’ai donc crédité 10€ sur mon compte. L’interface de gestion n’est pas la plus esthétique ni la plus rapide mais elle fait l’affaire.

En une petite dizaine de minutes, j’avais donc à ma disposition une machine virtuelle Debian Lenny 64-bits. Le réel inconvénient de l’offre d’OVH est que l’IP de la machine virtuelle change à chaque fois que vous l’arrêtez par le biais de l’interface de gestion.

L’installation de la pile LAMP est très simple et je ne la détaillerai donc pas ici. Il existe des masses incroyables de documentation à ce sujet.

Squid

L’installation de Squid est très simple. Je l’ai installé sur OpenSolaris à partir des dépôts Blastwave via pkgutil. Dans le cas de Debian, un apt-get s’occupera de tout ca pour vous.

Une fois installé, nous pouvons passer à sa configuration. La configuration du reverse proxy est la suivante :

http_port 80 accel defaultsite=www.antoinebenkemoun.fr
visible_hostname vm.antoine.fr
cache_peer 178.32.yy.xx parent 80 0 no-query originserver name=myAccel
acl all src 0.0.0.0/0.0.0.0
cache_peer_access myAccel allow all
acl our_sites dstdomain antoinebenkemoun.fr www.antoinebenkemoun.fr antoinebenkemoun.com www.antoinebenkemoun.com
http_access allow our_sites

Tout d’abord, on indique à Squid d’écouter les requêtes sur le port 80 et que le site que l’on va proxy-er est « www.antoinebenkemoun.fr ». Ensuite, on lui indique l’IP du serveur web où est réellement hébergé le site. Il est ensuite nécessaire de définir un certain nombre d’ACL qui sont ici assez génériques et tout à fait simples. Dans l’exemple, nous avons autorisé le reverse proxy pour 4 sites et nous avons autorisé toutes les IP à visionner le site.

Il est également possible d’utiliser d’autres options afin de mieux régler votre reverse proxy. L’ajout d’un « access log » va vous permettre de voir les pages qui sont consultés mais surtout si le contenu est envoyé par Squid ou par votre serveur LAMP. Il est également possible de régler la quantité de mémoire vive utilisé pour le cache de pages web. L’espace mémoire utilisé pour le cache sera donc alloué en plus de l’espace mémoire du programme principal.

cache_mem 20 MB
cache_access_log /opt/csw/var/logs/access.log

Le chemin pour l’access log est adapté à mon OpenSolaris mais à vous de l’adapter à votre distribution. Si vous êtes sur Linux, vous voudrez surement placer les logs quelque part dans /var/log/.

Au final, nous avons installé notre serveur Squid et l’avons configuré en mode reverse-proxy. Dans le billant suivant, nous verrons les modifications qu’il faut apporter à notre serveur Apache afin d’utiliser réellement la fonctionnalité de cache du reverse proxy.

Problématique

Le besoin initial de cette application est la gestion des règles iptables d’un parc de machines. En tant qu’administrateurs système, nous ne retrouvons régulièrement à gérer des scripts iptables sur divers serveurs. Lorsqu’on gère 5-10 serveurs, la gestion à la main reste acceptable. Cependant, dès que l’on commence à gérer plus de serveurs, ca commence à devenir réellement long et fastidieux. Et qui dit fastidieux dit fort potentiel d’erreurs.

J’ai donc entrepris de créer une application qui permettrait de gérer tout ca de manière un peu plus automatisée. L’application Netfilter Manager est donc née. Le nom est pas tout à fait extraordinaire mais ca représente à peu près ce que ca fait.

Présentation

Netfilter Manager utilise donc une interface en ligne de commande afin de pouvoir gérer un lot d’hôtes et les règles associées. Cette CLI est inspirée quelque peu de la CLI Cisco pour ceux qui ont déjà eu la chance l’occasion de l’utiliser. La licence de l’application est GPLv3. J’avoue ne pas être un expert dans le domaine des licences de logiciel mais c’est une des plus répandues et le peu que j’en connais me convient.

Chaque hôte dispose d’un nom et d’une adresse IP. A la place de l’adresse IP, on peut bien sûr utiliser un nom DNS que le serveur de gestion saura résoudre. L’application ne supporte que pour l’instant Iptables, il n’est donc pas encore possible de sélectionner un type d’hôte mais c’est une fonctionnalité envisageable.

Les règles sont ajoutées hôte par hôte et peuvent être organisées par ligne. Par défaut, les règles que vous ajoutées sont ajoutés à la suite des règles existantes. Il est possible de gérer plus finement l’ordonnancement des règles en utilisant la gestion par ligne. Chaque ligne peut comporter plusieurs règles et les règles seront appliquées dans l’ordre croissant des lignes. Ce comportement est très similaire au mode de fonctionnement des access-list Cisco.

Voici un petit exemple d’utilisation :

Il est également possible de créer des lots de règles grâce à un moteur de template dont l’utilisation est expliquée dans le README. Vous trouverez un exemple de template dans le fichier cobalt.tpl présent dans le répertoire templates.

Une fois que vous avez créé toutes les règles de firewall, vous allez pouvoir les « pousser » vers vos serveurs. Un script contenant les règles est généré en prenant les règles que vous avez spécifié et en ajoutant au début le contenu du fichier start.tpl. Par défaut, ce fichier contient des règles permettant de supprimer les règles iptables actuellement utilisées.

Pour en savoir plus sur l’utilisation de l’application, la commande help devrait pour vous aider. Sinon je vous conseille de lire le README (en anglais pour l’instant). J’espère que les explications sont claires et vous permettront de réussir à utiliser l’application. Si ce n’est pas le cas, vous pouvez me le faire savoir soit par ce blog soit par le bugtracker de github.

Bonus

En petit bonus, j’ai ajouté la possibilité de créer des règles en utilisant la syntaxe Cisco. Pour l’instant, seuls les règles IP sont supportées mais les règles TCP/UDP devraient également être supportées par la suite. Dans le mode ajout, il faut utiliser la commande access-list. Un page d’aide a été spécifiquement ajouté, vous pouvez y accéder en tapant access-list help. Je ne suis pas sûr que ce soit d’une utilité débordante mais ca m’a bien amusé de le coder.

Code

Tout le code de l’application est disponible sur github. Vous pouvez télécharger la version courante de l’application en cliquant sur ce lien.

Si vous souhaitez contribuer, vous êtes les bienvenus. Tout se passe via le git proposé par github. L’application est faite en Python et j’ai essayé de rendre le code le plus lisible possible. Si vous souhaitez effectuer des remontées de bugs ou me donner votre avis, vous pouvez le faire sur ce blog ou sur github.

En Avril, j’avais écrit un petit billet sur la génération de certificats OpenVPN par lots ce qui est bien pratique lorsqu’on doit en générer une quantité importante. J’ai à nouveau rencontré cette problématique mais dans un contexte légèrement différent. Sous Ubuntu Server 10.04, le jeu d’outils Easy-RSA d’OpenVPN n’utilisent plus OpenSSL directement mais utilisent pkitool qui ne semble être qu’un intermédiaire de simplification.

Du coup, le script donné précédemment n’est plus valable. Il a donc fallu trouver une parade assez simple mais non moins fonctionnelle. La solution adaptée à pkitool ne tient plus qu’en un seul script qui est le suivant.

#! /bin/bash

# Make a certificate/private key pair using a locally generated

# root certificate.

export EASY_RSA= »`pwd` »

export OPENSSL= »openssl »

export PKCS11TOOL= »pkcs11-tool »

export GREP= »grep »

export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`

export KEY_DIR= »$EASY_RSA/keys »

export PKCS11_PIN= »dummy »

export KEY_SIZE=1024

export CA_EXPIRE=3650

export KEY_EXPIRE=3650

export KEY_COUNTRY= »FR »

export KEY_PROVINCE= »FR »

export KEY_CITY= »Paris »

export KEY_ORG= »Antoine-Corp »

export KEY_EMAIL= »me@myhost.mydomain »

export KEY_CNAME=$1

export EASY_RSA= »${EASY_RSA:-.} »

« $EASY_RSA/pkitool » $*

Le tour est joué ! Vu que WordPress (ou plutôt de ces modules/thèmes) remplace les quotes par des guillemets impossibles à copier/coller dans un shell, je vous mets à disposition une version en texte brut jusqu’à ce que j’ai réussi à résoudre ce problème assez agaçant.

Au final, ce script devrait vous être utile pour générer rapidement des certifications OpenVPN à la pelle et ainsi vous simplifier la vie.

Définition

Les réseaux de distribution de contenu sont des réseaux qui ne ressemblent pas aux réseaux traditionnels. Traditionnellement, un réseau est présent dans un endroit ou dans plusieurs. Pour les réseaux d’entreprise, ils sont présents sur le siège social, les diverses succursales et éventuellement un centre de données. Dans le cas des réseaux d’opérateur, ils couvrent un pays ou bien plusieurs avec plusieurs points d’interconnexions dans le monde.

Les réseaux de distribution de contenu sont éclatés à travers le monde. Leur objectif est d’être présent dans le plus d’endroits possibles afin de fournir du contenu au plus proche de l’utilisateur. Nous avons donc à faire à des réseaux multi-localisés.

Positionnement stratégique

L’intérêt même des réseaux de distribution de contenu est leur présence dans les endroits « stratégiques » de l’Internet. Leur objectif est de réduire les coûts de distribution de contenu en se rapprochant de l’utilisateur final. Il leur est donc très intéressant de se rapprocher des noeuds d’interconnexion de l’Internet mais également des fournisseurs d’accès à Internet.

Leur présence dans les locaux des fournisseurs d’accès permet une très forte réduction des coûts de bande passante. Du point de vue du fournisseur d’accès à Internet, il ne crée pas de trafic supplémentaire avec le reste du monde. C’est précisément ce type de trafic réseau vers le reste du monde qui est couteux. Le FAI ont donc tout intérêt à intégrer des CDN dans son réseau. Au lieu d’envoyer n-fois un contenu sur un lien interocéanique, il suffira de l’envoyer une fois et il sera ensuite redistribué à partir du réseau du FAI.

La proximité géographique n’est pas forcément synonyme de proximité au niveau de l’Internet. Les nœuds de l’Internet ne répondent aux mêmes logiques de proximité que les réseaux routiers. Les grands nœuds d’interconnexion européens sont Londres et Amsterdam. Il sera donc parfois plus rapide voire nécessaire de router un flux via ces villes pour accéder un pays voisin ce qui est contraire à la simple proximité géographique.

Données statiques

Les réseaux de distribution de contenu distribuent essentiellement des données statiques. Par données statiques, j’entends des données qui ne varient pas dans le temps. La vidéo peut donc être considéré comme un contenu statique dans le cas de vidéos Youtube par exemple. Les CDN ne disposent normalement pas de ressources de calcul de scripts type PHP, ASP ou autre.

L’exception à cette affirmation est le contenu vidéo diffusé en direct. Les CDN peuvent être utilisés pour diffuser ce type de contenu. Mais il reste invariant du point de vue des utilisateurs. Chaque utilisateur reçoit le même contenu avec un décalage minimal.

Au final, nous avons réussi à faire un tour rapide de la définition des réseaux de distribution de contenu. Il serait possible de s’étendre longuement sur ce sujet mais ce n’est pas le but ici. Nous verrons par la suite les techniques d’accès au contenu et de répartition de charge.

Avant de rentrer dans le vif du sujet, la présentation que nous avons effectué est disponible sur Slideshare. L’affichage des animations est quelque peu fastidieux par le biais de la visionneuse Slideshare mais ca reste assez lisible. Il s’agit d’une présentation Keynote contenant assez peu de détails car la plupart du sujet a été traité à l’oral. Pour le détail, il faudra lire les articles de cette série de billets.

Tout d’abord, nous pouvons traduire le terme « Content Delivery Network » par « Réseau de distribution de contenu ». L’adaptation de ce terme en Français me semble tout à fait satisfaisante. J’utiliserais ce terme pour la suite des billets et les autres billets à venir. Je ferais une exception pour le titre mais ça c’est pour l’indexation Google.

Les réseaux de distribution de contenu ont été conçus pour répondre à des problématiques très concrètes rencontrées sur Internet. Lors de cette introduction, nous nous attacherons à identifier ces problématiques et à les détailler. Nous distinguerons deux types de problématiques : les nouvelles problématiques et les problématiques historiques.

Nouvelles problématiques

L’utilisation de l’Internet a beaucoup évolué depuis ces dix dernières années et ces évolutions ont amené de nombreuses nouvelles problématiques.

La première grande révolution est l’introduction de la vidéo dans le navigateur web. Ceci peut paraitre tout à fait « normal » aujourd’hui mais l’intégration de contenus vidéos était quelque chose de rare il y a une dizaine d’années. Le lecteur Real Player avait permis de faire les premiers pas vers cette intégration mais son utilisation était exceptionnellement pénible. Ceux qui l’ont utilisé se souviendront probablement du casse tête entre les version gratuites et payantes ainsi que les publicités associées. Cette révolution a permis au plus grand monde d’accéder à des quantités de contenu astronomiques.

La seconde révolution est le haut débit par le biais des technologies de transmission ADSL et câble. Chaque utilisateur connecté derrière la box de son fournisseur d’accès à Internet obtient ainsi la possibilité de récupérer des données à une vitesse particulièrement élevée. Aujourd’hui, la quasi totalité des accès ADSL/Câble classiques disposent de plusieurs Mégabits de débit.

La troisième révolution a été les réseaux sociaux. Dans l’absolu, les réseaux sociaux ne sont que des sites comme des autres. Leur particularité réside dans le fait que la quantité de contenu qui y est ajouté chaque heure est colossale. De plus, ces contenus sont consultés de manière régulière par de nombreuses personnes à longueur de journée.

Pour résumer, le contenu distribué sur Internet a largement grossi à cause de la vidéo mais les utilisateurs ont également la possibilité de le récupérer à des vitesses élevés. Au final, il était nécessaire de trouver un solution efficace et le moins cher possible car tous ses contenus sont accessibles gratuitement.

Problématiques historiques

Nous venons de voir un certains nombre de facteurs récents qui ont modifié l’utilisation de l’Internet. Nous allons maintenant nous intéresser aux problématiques qui ne sont elles pas récentes.

La première problématique est le coût de la mise en place des liaisons transocéaniques et transcontinentales. L’investissement initial est élevé et la maintenance sur ces câbles est exceptionnellement compliquée. Les procédés de fabrication des fibres ont été améliorés et leur utilisation a été optimisé mais il reste nécessaire de faire traverser l’océan par un navire câblier ou bien de creuser les trous pour enfouir les fibres. Cette problématique induit le fait que plus le trafic réseau parcourt de la distance, plus les couts sont élevés.

La seconde problématique est la vitesse de la lumière. Transcrit en des termes plus informatiques, la seconde problématique est la latence. Cette dernière est bornée inéluctablement par la vitesse de propagation d’un signal dans une fibre optique qui dépend de la vitesse de la lumière. Les utilisateurs veulent non seulement du contenu mais le veulent rapidement. La latence peut devenir un problème dans le cas de liaisons transocéaniques. Des chiffres donnés par Akamai évoquent une latence de 1,6 ms pour du contenu situé à 160 Km et une latence de 96 ms pour du contenu situé sur un autre continent.

Au final, ces deux jeux de problématiques s’additionnent et viennent compliquer la vision traditionnelle de la distribution de contenu sur Internet. Les réseaux de distribution de contenu ont été créé dans l’objectif de résoudre au mieux à toutes ces problématiques.

La méthode la plus simple consiste à utiliser les outils easy-rsa en ligne de commande. Ces outils simplifient réellement la tâche par rapport à l’utilisation directe d’OpenSSL. Le problème avec l’utilisation de ces outils est la nécessité d’interagir avec le terminal. Cet outil va vous demander bon nombre de renseignements tels que le pays, la ville, l’adresse email, etc. Cette interaction rend compliquée la création par lots de certificats.

Une méthode plus compliquée, mais plus efficace, consiste à adapter les scripts easy-rsa afin de rendre leur utilisation plus linéaire et non interactive afin qu’un script puisse les exécuter. De plus, j’ai souhaité donner la possibilité de spécifier la durée de validité du certificat au cas par cas, ce qui n’est pas possible par défaut.

Le premier script, build-key-batch, permet de créer une clé en spécifiant une durée de validité. Il n’y a qu’une toute petite modification qui permet de récupérer la durée de validité passée en argument.

#!/bin/sh

if test $# -ne 2; then
     echo « usage: build-key-batch <name> <duree> »;
     exit 1
fi

if test $KEY_DIR; then
     cd $KEY_DIR && \
     openssl req -days $2 -nodes -new -keyout $1.key -out $1.csr -batch -config $KEY_CONFIG && \
     openssl ca -days $2 -out $1.crt -in $1.csr -batch -config $KEY_CONFIG && \
     chmod 0600 $1.key
else
     echo you must define KEY_DIR
fi

Par défaut, easy-rsa nécessite d’exécuter le fichier vars dont le rôle est d’exporter un certain nombre de variables d’environnement utilisées par les scripts de génération de clé. Cela ne me convenait pas car je souhaitais exécuter un seul fichier contenant toutes les informations dont je pouvais avoir besoin. J’ai donc créé un script nommé build-batch qui contient toutes les options.

#!/bin/sh
if test $# -ne 2; then
     echo « usage: batch-build <name> <duree> »;
     exit 1
else
     # Definition des variables
     export D=`pwd`
     export KEY_CONFIG=$D/openssl.cnf
     export KEY_DIR=$D/keys
     export KEY_SIZE=1024
     export KEY_COUNTRY=FR
     export KEY_PROVINCE=XX
     export KEY_CITY=Paris
     export KEY_ORG= »Keeyyyy »
     export KEY_EMAIL= »$1″
     export KEY_CNAME=$1
     ./build-key-batch $1 $2
fi

Ce script nécessite une petite modification du fichier openssl.cnf présent dans le dossier easy-rsa qui est la suivante :

commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
++ commonName_default = $ENV::KEY_CNAME

Le script a exécuter afin de générer un certificat est donc build-batch suivi de deux arguments qui sont le nom du certificat et la durée de validité. Vous pourrez ainsi générer des certificats pour OpenVPN simplement et efficacement sans nécessiter une intervention humaine.

Source : insights

Je ne referais pas de bilan spécifique car ce dernier a déjà été fait dans un billet précédent. Je n’ai pas d’élément à ajouter à ce que j’ai déjà dit précédemment. Malgré quelques problématiques humaines, je suis satisfait du réseau que nous avons mis en place lors de cette édition de l’Utt Arena.

Pour commencer cette conclusion, voici un récapitulatif de tous les billets de cette série :

• Architecture réseau d’une LAN Party : Introduction
• Architecture réseau d’une LAN Party : Conception
• Architecture réseau d’une LAN Party : Filtrage
• Architecture réseau d’une LAN Party : Configuration des ASA
• Architecture réseau d’une LAN Party : DHCP
• Architecture réseau d’une LAN Party : La latence
• Architecture réseau d’une LAN Party : Premier bilan

Ensuite, je vous ai fait un paquet avec toutes les configurations des équipements. Il s’agit des configurations que nous avons sauvegardé à la fin de l’événement, elle n’inclut donc pas la configuration avant la transition vers les ASA. Pour rappel, les 3750 s’appellaient Kilimandjaro et StHelens et les ASA s’appellaient Etna, Kilauea, Fuji et Pinatubo.

Nous avons mis en place une weathermap lors de l’événement dont voici une capture. A ce moment, les joueurs tentaient de récupérer le GUI CS:Source. La bande passante du serveur étant limitée à 100Mbit/s, la montée en couleur a été réduite. Si vous souhaitez visionner la carte en taille réelle, il suffit de cliquer dessus.

Les résultats de Smokeping ont été également très satisfaisants. La capture d’écran ci-dessous montre un graph de la latence entre le serveur Smokeping et une interface IP d’une 3750 dans le LAN des joueurs. Les données avant le « trou » correspondent aux mesures faites avant la transition vers les ASA. On remarque un pic de latence suite à la transition. Cela correspond à la récupération du GUI par les joueurs et n’a donc pas impacté les tournois.

Pour ceux que cela pourrait intéresser, j’ai fait un paquet contenant de nombreux graphs que j’ai pu sauvegarder le dernier jour de la LAN avant de tout déconnecter. Il y a de nombreux graphs incluant notamment les uplinks vers les tables et les interfaces des ASA.

Au final, la gestion du réseau de cet événement fut un réel plaisir et m’a permis d’acquérir de nouvelles compétences notamment au niveau de l’utilisation des Cisco ASA et 3750 mais aussi des outils Cacti et Smokeping. Ici s’achève donc la plus longue série de billets de ce blog jusqu’à présent.

Phase 1

Tout d’abord, nous n’avions pas la possibilité d’avoir les équipements réseau type Cisco ASA et 2800 avant le Samedi midi car ils n’arrivaient pas avant ce moment là. Nous avons donc du faire avec une solution secondaire par le biais des 3750. Cela était parfaitement prévu depuis quelques semaines mais je n’avais pas souhaité en parler afin d’éviter l’effet placebo lors de la transition vers le réseau définitif.

La mise en place des deux 3750 s’est faite sans aucun soucis particulier. Le premier 3750 nommé Kilimandjaro disposait d’une interface IP dans tous les VLAN et effectuer le routage entre ces derniers. Le second 3750 nommé StHelens avait pour seule fonctionnalité la commutation des paquets associées à ses interfaces. Nous avions également prévu ce second 3750 afin d’avoir une solution de secours en cas de panne du premier 3750.

Transition

Lorsque les ASA sont arrivés, nous avons dû effectuer la transition du réseau initial vers le réseau prévu. Les joueurs n’ont pas été mis au courant de ce changement afin d’éviter un effet placebo qui correspondrait à voir des pannes partout sans réelle raison. Les organisateurs ont cependant été mis au courant ce qui a provoqué une avalanche de remontées de problèmes divers et, en grande partie, sans aucun rapport avec transition. La gestion des remontées de ces problèmes a été plutôt mauvaise car tous les organisateurs remontaient vers l’équipe réseau tous les problèmes, incluant ceux n’ayant aucun rapport de près ou de loin avec le réseau.

Nous avons racké les ASA dans la baie prévue à cet effet. J’évoquerais l’architecture physique ultérieurement. Nous avons ensuite injecté les configurations en port série et nous avons validé que nous avions bien un accès Telnet à ses équipements afin d’éviter de mauvaises surprises. Nous avons ensuite connecté tous les ports de Management et d’interconnexion des ASA afin qu’ils prennent connaissance de la topologie IP. Nous avons ensuite basculé les interfaces IP du 3750 vers les ASA une par une. Nous avons tout de même laissé une interface par VLAN sur les 3750 pour la fonctionnalité DHCP. Pour les routeurs, nous avons appliqué une méthodologie similaire.

Lors de la transition, nous avions donc une partie des VLAN routés par le 3750 et une partie des VLAN routés par les ASA/2800. Cette configuration temporaire a impliqué un routage asymétrique. Autant les routeurs sont peu sensibles aux asymétries de routage, les ASA ne le sont pas car ils effectuent un suivi de la session TCP. Nous avons réussir à contenir en bonne partie l’asymétrie du routage en jouant avec les identifiants de routeur OSPF ou du moins on pense que ce fut le cas. De toute manière, la transition a duré une petite heure.

Une fois la topologie reconstituée, nous avons coupé l’OSPF sur le 3750 afin qu’il soit exclu du processus de routage et nous avons laissé les ASA et les 2800 faire leur travail. Une coupure d’une trentaine de secondes est induite par la réélection OSPF et le recalcul des routes.

Phase 2

Une fois toute l’architecture en place, nous avons pu commencé à débugger nos configurations. Nous avons essentiellement eu des soucis de configuration de VLAN sur les switchs que nous avons mis un peu de temps à corriger. Les remontées de problèmes pertinentes ont mis un peu de temps à nous parvenir réellement car elles étaient noyées dans un volume assez important de demandes.

Nous n’avons pas rencontré de problème particulier lié à notre architecture réseau suite aux reconfigurations initiales. Les joueurs Warcraft III ont rencontré de nombreux problèmes de connexion aux parties alors qu’ils étaient tous dans le même VLAN voire sur le même switch. Nous n’avons pas réussi à déterminer l’origine de ce problème épisodique. La piste d’un applicatif malicieux est privilégiée car de multiples changements de switch et un passage en IP fixe n’ont apporté aucune solution à ce problème. La latence est tout à fait correcte selon nos mesures bien que nous rencontrons quelques problèmes du coté des serveurs CSS qui se montrent quelque peu capricieux. Nous avons mis le LLQ pour le principe mais la différence de latence ne parait pas significative.

Au final, la préparation nous a permis d’effectuer une transition propre et plutôt efficace. La vraie difficulté a été la qualification et la pertinence des problèmes remontés aux administrateurs réseaux. Je referais un point une fois l’évènement passé.