Nous allons dans ce billet tester la version 1.2.5 de NConf sur un serveur Nagios 3.1. Je pars sur l'hypothèse ou le serveur Nagios a été installé en suivant mes deux premiers tutos (1 et 2).

Installation de NConf

On commence par récupérer la dernière version disponible de NConf (la 1.2.5 au moment de l'écriture de ce billet).

wget http://puzzle.dl.sourceforge.net/sourceforge/nconf/nconf-1.2.5-0.tgz

On décompresse l'archive:

tar zxvf nconf-1.2.5-0.tgz

Puis on copie le répertoire nconf à la racine de son serveur Web et on change les droits:

sudo mv nconf /usr/local
sudo chown -R www-data:www-data /usr/local/nconf

Notes: les sous-répertoires suivants doivent avoir les droits en écriture pour l'utilisateur www-data:
./config
 ./output
 ./static_cfg
 ./temp

Création de la base de donnée

La prochaine étape consiste à créer une base de données dédiée ) NConf. Pour créer un base de donnée nommée nconf avec les droits pour l'utilisateur nconfuser (mot de passe: nconfpassword), il faut saisir les commandes suivantes sur son serveur MySQL:

# mysqladmin --user=root -p create nconf

# mysql --user=root -p mysql

mysql> GRANT ALL ON nconf.* TO nconfuser@localhost IDENTIFIED BY 'nconfpassword';

mysql> flush privileges;

Configuration du serveur Web

Pour rendre accessible le répertoire /usr/local/nconf à partir de votre serveur Web, il faut ajouter le fichier de configuration /etc/apache2/conf.d/nconf.conf dans votre configuration Apache:

Alias /nconf /usr/local/nconf/
<Directory "/usr/local/nconf">
    Options Indexes
    AllowOverride AuthConfig Options
    Order allow,deny
    Allow from all
</Directory>

Puis relancer Apache:

apache2ctl restart

Configuration de NConf

La fin de l'installation se fait via une interface Web. Il faut donc saisir l'URL suivante dans un navigateur:

Ce qui devrait afficher:

On clique sur le bouton Next.

On doit saisir les paramètres de la base de donnée préalablement créées:

On clique sur le bouton Next.

Le test de la BD doit être OK:

On clique sur le bouton Next.

On fixe les répertoires de Nconf et de Nagios (/usr/local/nagios/bin). Attention dans le champs NAGIOS BIN, il faut saisir le chemin complet vers le binaire de Nagios (/usr/local/nagios/bin/nagios) et pas seulement le répertoire comme je l'ai fait dans un premier temps dans cette capture d'écran...

On clique sur le bouton Next.

On fixe un mot de passe (adminpassword) pour l'accès à NConf:

On clique sur le bouton Next.

Le programme d'installation va vérifier la configuration (tout doit être OK):

On clique sur le bouton Finish.

On efface les fichier suivant:

sudo rm -r /usr/local/nconf/INSTALL /usr/local/nconf/INSTALL.php /usr/local/nconf/UPDATE /usr/local/nconf/UPDATE.php

Mise en place de la synchronisation avec Nagios

Comme NConf peut être hébergé sur une machine différente du serveur Nagios, l'importation de la configuration NCOnf vers Nagios doit se faire à la main ou par un script shell. Je préfére bien entendu cette deuxième méthode.

Avant tout, il faut vérifier que le répertoire Nagios à les bon droits en lecture et écriture pour être modifié par l'utilisateur www-data (utilisateur avec lequel le serveur Apache est lancé). Le plus simple est d'ajouter www-data au groupe nagiosgrp:

# vigr
nagiosgrp:x:1002:nagios,www-data

puis de mettre les bons droits au répertoire etc:

chown -R nagios:nagiosgrp /usr/local/nagios/etc
chmod 770 /usr/local/nagios/etc

J'ai ensuite modifié le script ADD-ONS/deploy-local.sh de la manière suivante:

#!/bin/bash
OUTPUT_DIR="/usr/local/nconf/output/"
NAGIOS_DIR="/usr/local/nagios/etc/"
TEMP_DIR=${NAGIOS_DIR}"import/"
CONF_ARCHIVE="NagiosConfig.tgz"
if [ ! -e ${TEMP_DIR} ] ; then
mkdir -p ${TEMP_DIR}
fi
if [ ${OUTPUT_DIR}${CONF_ARCHIVE} -nt ${TEMP_DIR}${CONF_ARCHIVE} ] ; then
cp -p ${OUTPUT_DIR}${CONF_ARCHIVE} ${TEMP_DIR}${CONF_ARCHIVE}
tar -xf ${TEMP_DIR}${CONF_ARCHIVE} -C ${NAGIOS_DIR}
/etc/init.d/nagios reload
fi
exit

Il ne reste plus qu'a l'éxecuter de manière automatique (par exemple toutes les 5 minutes) via un crontab root:

# crontab -e
*/5 * * * * /bin/bash /usr/local/nconf/ADD-ONS/deploy_local.sh 2>&1 > /dev/null

Utilisation de NConf

La première chose à faire est de se connecter à l'interface Web et de s'authentifier (admin/adminpassword). La page suivante devrait s'afficher:

On va tester notre nouvelle interface en ajoutant un nouvel host dans Nagios. Pour cela on clique sur le menu "Hosts Add" de NConf:

On clique ensuite sur Submit.

On peut alors choisir les services à superviser (il est bien sûr possible d'ajouter des services via NConf):

On clique ensuite sur Submit.

Une dernière page s'affiche avec le résumé:

On clique sur Finish.

NConf vient ainsi d'ajouter ce nouvel host dans sa base de donnée. En cliquant maintenant sur le lien "Generate Nagios config", on va générer les fichiers de configuration de Nagios dans un NagiosConfig.tgz se trouvant dans le répertoire  /usr/local/nconf/output.

Il ne reste plus qu'a attendre le prochain lancement du script deploy-local.sh (dans les 5 minutes via crontab) pour que le host apparaisse dans Nagios:

Conclusion

Bien qu'en développement, NConf est très prometteur et comble le vide laissé par Nagios pour l'administration via une interface Web. L'idéal serait maintenant d'intégrer cette interface dans celle de Nagios (le hack ne doit pas être très difficile à faire) afin de ne pas avoir deux interfaces (NConf et Nagios).

A vous de tester maintenant...

Ce support comprend l'accès à des équipes d'experts dédiés disponible un peu partout sur la planète (pas de problème de décalage horaire), un accès à un gestionnaire de tickets pour saisir et suivre vos appels. Une base de connaissance publique (documentation, FAQ) est également disponible.

Le prix annuel pour l'accès à ce support commence à  $2495 (soit environ 1766 Euros). Comme quoi il est possible d'associer business et open-source...

Vous êtes coincé à votre bureau, derrière un beau Firewall qui bloque, mis à part le HTTP, tous les autres protocoles. Au même moment, le site Web hébergé sur votre serveur perso plante... Dans ce cas, il faut attendre le soir, rentrer chez vous pour enfin pouvoir se connecter en SSH sur votre serveur et résoudre le problème.

Il existe cependant une astuce qui moyennant un brin de préparation va vous permettre de faire passer le SSH à travers ce vilain Firewall...

Principe

La théorie est la suivante: nous allons créer un tunnel HTTP entre le PC du bureau et le PC de la maison. C'est possible car le tunnel est basé sur un protocole autorisé par le Firewall de votre entreprise (HTTP dans notre cas mais vous pouvez utiliser n'importe quel protocole TCP). Ensuite, il faudra rediriger sur votre PC de bureau le protocole SSH vers le tunnel HTTP. Une fois que les paquets SSH sont récupérés sur le PC maison, il n'a qu'a les envoyer vers votre serveur.

   

Préparation de la configuration maison

On commence par installer le logiciel HTTPtunnel sur notre PC maison (exemple d'installation sous Ubuntu):

sudo apt-get install httptunnel

Ensuite on lance la commande suivante:

sudo hts --forward-port A.B.C.D:22 80

Cette commande va écouter sur le port TCP/80 (comme c'est un port < 1024 on doit lancer cette commande en root, d'ou l'utilisation de sudo) et rediriger le trafic vers le serveur (d'adresse ip A.B.C.D dans mon exemple) et sur le port SSH (TCP/22).

Ensuite il faut penser à configurer votre *box pour:

• autoriser les flux HTTP (TCP/80) entrant à destination de l'adresse publique de la *box votre maison (règle de Firewall)
• rediriger les flux HTTP (TCP/80) à destination de l'adresse publique de la *box votre maison vers l'adresse privé de votre PC maison (règle de NAT/PAT)

Configuration du PC bureau

Si vous avez la chance de travailler sur un OS de type GNU/Linux à votre bureau, la prcédure est alors relative simple.

On commence par installer HTTPtunnel sur notre PC bureau (exemple d'installation sous Ubuntu):

sudo apt-get install httptunnel

Ensuite on lance la commande suivante:

htc --forward-port 2222 E.F.G.H:80

Cette commande va écouter sur le port TCP/2222 (comme c'est un port >
1024, il n'est pas nécessaire de lancer cette commande en root)
et rediriger le trafic vers le PC maison (d'adresse ip E.F.G.H dans mon
exemple) et sur le port HTTP (TCP/80).

Si votre entreprise oblige les flux Web à transiter par un proxy HTTP (d'adresse S.Q.U.I avec une authentification USER/PASSWORD), il faudra ajouter les paramètres suivants à la ligne de commande:

htc -P S.Q.U.I --proxy-authorization USER:PASSWORD --forward-port 2222 E.F.G.H:80

Dans le cas ou votre PC de bureau est sous Windows (snif), il va falloir passer par une configuration du client Putty par exemple en suivant cette procédure.

Lancement du client SSH

Il suffit de lancer la commande suivante à partir de votre PC de bureau:

ssh localhost -p 2222

Vous serez alors connecté sur votre serveur !

Voici donc dans ce billet une procédure très simple pour installer la version 1.7 de VnStat sur un système GNU/Linux (Ubuntu ou Debian) et donc disposer de VnStati...

Installation des pré-requis

Pour compiler correctement, Vnstat a besoin de quelques librairies:

sudo apt-get install libgd2-noxpm libgd2-noxpm-dev

Compilation et installation de VnStat

On commence par récupérer la dernière version disponible de VnStat

wget http://humdi.net/vnstat/vnstat-1.7.tar.gz

On décompresse et on compile:

tar zxvf vnstat-1.7.tar.gz
cd vnstat-1.7/
make all

Puis on installe sur notre système:

sudo make install

Et voili...

VNStat est un petit utilitaire bien sympathique pour surveiller la bande passante utilisée sur les interfaces réseaux de ses machines GNU/Linux ou BSD.

Installation de VNstat

Sous GNU/Linux Ubuntu:

# sudo apt-get install vnstat

Puis ajouter la ligne suivant dans votre crontab:

*/5 * * * * root if [ -x /usr/bin/vnstat ] && [ `ls -l /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi

Sous FreeBSD:

# pkg_add -r vnstat

Puis ajouter la ligne suivant dans votre crontab:

*/5 * * * * root if [ -x /usr/local/bin/vnstat ] && [ `ls -l /var/db/vnstat/ | wc -l` -ge 1 ]; then /usr/local/bin/vnstat -u; fi

Déclaration des interfaces réseaux à surveiller

Imaginons que la machine à surveiller est un routeur avec deux interfaces réseaux: em0 qui est l'interface coté Internet (c'est à dire l'interface connecté à votre modem/routeur DSL) et em1 qui est l'interface coté LAN (celle connecté à vos machines).

Il faut donc effectuer la déclaration suivante qui va créer automatiquement les fichiers de base de données.

# vnstat -u -i em0 --nick "Internet"
# vnstat -u -i em1 --nick "LAN"

Utilisation de VNStat

Le crontab que nous avons configuré dans la première étape de l'installation est programmé pour se lancer toutes les 5 minutes. Il faut donc attendre un petit moment avant de pouvoir utiliser VNStat.

La première commande permet d'afficher un résumé des statistiques par interface.:

# vnstat
                     rx      /     tx      /    total    /  estimated
Internet (em0):
     yesterday    421.40 MB  /  984.95 MB  /    1.37 GB
         today     91.20 MB  /   86.35 MB  /  177.54 MB  /     294 MB

LAN (em1):
     yesterday    626.97 MB  /  242.34 MB  /  869.32 MB
         today      1.46 GB  /  565.40 MB  /    2.01 GB  /    3.36 GB

Statistiques sur la dernière heure avec l'option -h:

# vnstat -h
 Internet (em0)                                                           14:25
  ^                                                        r                   
  |                                                        r                   
  |                                                        r                   
  |                                                        r                   
  |                                                        r                   
  |                                                        r                   
  |                                                        r                   
  |     r                                                  r     r             
  |     r                                                  r  r  r             
  |  r  r  r                  t                 t  t       r  r  rt r  r       
 -+--------------------------------------------------------------------------->
  |  15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14   
                                                                               
 h   rx (kB)    tx (kB)      h   rx (kB)    tx (kB)      h   rx (kB)    tx (kB)
15     117458      17933    23       7006      69069    07       4913      31545
16     205687      21665    00      26175      23108    08      61198      19855
17     112410      14211    01       5373       5281    09     682414      39748
18       4981       6441    02       3734       4623    10     191760      16684
19       5792      42644    03       3822       4842    11     238408      95350
20       4211       4416    04      31824      23303    12     135037      37811
21       5571       6457    05      17429     111179    13      91544      24793
22       5680      32557    06       6706     135740    14      40126       6404

Statistiques journalières avec l'option -d:

# vnstat -d
 Internet (em0)  /  daily

    day         rx      |     tx      |  total
------------------------+-------------+----------------------------------------
   14.04.    626.97 MB  |  242.34 MB  |  869.32 MB   %%%%%%%:::
   15.04.      1.47 GB  |  566.67 MB  |    2.02 GB   %%%%%%%%%%%%%%%%%%:::::::
------------------------+-------------+----------------------------------------
 estimated     2.43 GB  |     937 MB  |    3.35 GB

Statistiques hebdomadaire avec l'option -w:

# vnstat -w
    Internet (em0)  /  weekly

                        rx      |       tx      |    total
    ----------------------------+---------------+--------------
      last 7 days      2.09 GB  |    810.27 MB  |      2.89 GB
     current week      2.09 GB  |    810.27 MB  |      2.89 GB
    ----------------------------+---------------+--------------
        estimated      5.67 GB  |      2.14 GB  |      7.82 GB

Statistiques mensuelle avec l'option -m:

# vnstat -m
Internet (em0)  /  monthly

   month         rx      |      tx      |   total
-------------------------+--------------+--------------------------------------
  Apr '09       2.09 GB  |   810.27 MB  |     2.89 GB   %%%%%%%%%%%%%%%%::::::
-------------------------+--------------+--------------------------------------
 estimated      4.31 GB  |     1.63 GB  |     5.93 GB

D'autres options permette d'avoir une vu en "temps réel" de la consomation de bande passante:
 
Calcul sur les 5 dernières secondes:

# vnstat -tr
19 packets sampled in 5 seconds   
Traffic average for em4

      rx           0.14 kB/s              2 packets/s
      tx           0.13 kB/s              1 packets/s

Calcul instantané:

# vnstat -l
Monitoring em0...    (press CTRL-C to stop)

   rx:       2.36 kB/s    11 p/s            tx:       1.46 kB/s    13 p/s

Le texte c'est bien , mais les graphes c'est mieux

Si vous avez l'âme d'un futur manager, vous êtes en train de vous dire que cet utilitaire n'est pas mal mais qu'une présentation sous forme de graphe ferait un plus bel effet dans mon prochain rapport... Heureusement, les auteurs de VNStat ont pensé à vous et vous proposent VNStati.

L'utilisation est presque la même que pour VNStat. La première commande permet de génèrer (au format PNG) un résumé des statistiques par interface (utiliser l'option -i pour fixer l'interface):

# vnstati -i em0

Statistiques sur la dernière heure avec l'option -h:

# vnstat -h

Statistiques journalières avec l'option -d:

# vnstat -d

Statistiques mensuelle avec l'option -m:

# vnstat -m

Conclusion

Bien que VNStat ne boxe pas dans la même catégorie que des logiciels comme Cacti, je trouve que c'est un bon complément à des outils comme iftop ou ntop (en beaucoup plus léger pour ce dernier). Il existe même un projet parallèle pour intégrer ces rapports dans un site Web à partir d'un front-end PHP (projet vnStat PHP frontend).

Avant de nous plonger dans le vif du sujet et si vous souhaitez faire ces tests chez vous, il faut au préhalable installer GStreamer sur votre système.

Ma configuration de test est la suivante:

Lors de la rédaction de ce billet, j'ai utilisé la caméra AXIS 213:

Affichage du flux vidéo

Cette caméra (comme toutes les caméras AXIS) permet la diffusion sur le réseau en utilisant deux formats:

• MJPEG sur HTTP
• MPEG-4 sur RTSP

Affichage du flux MJPEG/HTTP

On lance la commande suivante sur la machine PC1:

gst-launch gnomevfssrc location=http://cam01/axis-cgi/mjpg/video.cgi?resolution=CIF ! jpegdec ! ffmpegcolorspace ! autovideosink

Un rapide ntop sur notre machine PC1 nous indique que le fux est gourmand en bande passante (de l'ordre de 3.3 Mbps). L'occupation CPU varie entre 20% et 60%. La vidéo est fluide.

Affichage du flux MPEG4/RTSP

On lance la commande suivante sur la machine PC1:

gst-launch-0.10 rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! decodebin ! ffmpegcolorspace ! autovideosink

La bande passante entre la caméra et le PC1 est alors de 1 Mbps en pics (moyenne de 400 Kbps quand il y a peu de mouvement devant la caméra). L'occupation CPU varie entre 5% et 15%. La vidéo est fluide.

Le paramètre latency (qui est par défaut à 3000, soit 3 secondes) permet de réduire la taille du buffer d'entrée. Si vous êtes sur un réseau LAN, vous pouvez sans problème mettre comme valeur 0 (comme je l'ai fait dans mon exemple). Par contre sur des réseaux moins performant (en terme de débit, de perte de paquets...), il vaut mieux conserver un buffer un peu plus élevé.

Encodage du flux vidéo dans un fichier

Nous allons continuer notre test en essayant d'encoder "à la volée" le flux vidéo venant de la caméra IP. Détaillons un peu notre pipeline:

• récupérer le flux MPEG4/RTSP de la caméra
• l'afficher sur l'écran
• réduire le nombre d'images par seconde (fps) à 1
• encoder le flux en MJPG
• sauvegarder dans un fichier AVI (output.avi)

La ligne de commande correspondante à lancer sur PC1 est:

gst-launch rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! tee name=save ! queue ! autovideosink save. ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)1/1" ! queue ! jpegenc ! avimux ! filesink location=output.avi .save

Le fichier généré (output.avi) occupe un espace disque d'environ 15 Ko par seconde (soit 54 Mo/heure).

Afin d'optimiser cette taille, il est possible d'utiliser Theora (dans un fichier OGG), un codec vidéo libre et efficace. La commande devient alors:

gst-launch rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! tee name=save ! queue ! autovideosink save. ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)1/1" ! queue ! theoraenc ! oggmux ! filesink location=output.ogg .save

On a alors une taille de fichier de sortie (output/ogg) d'environ 6 Ko par seconde (soit 21 Mo/heure).

Mixer plusieurs vidéos en une

Si vous disposé de plusieurs caméras, il peut être utile de mixer ces différentes sources dans une même image (un peu comme le mode PIN des télévisions).

Je vais dans l'exemple ci-dessous, prendre deux sources (Camera AXIS + Webcam USB) et les mixer:

La pipeline est la suivante:

gst-launch  v4l2src ! queue ! videoscale ! capsfilter caps="video/x-raw-yuv,width=64,height=48,framerate=(fraction)5/1" ! ffmpegcolorspace ! videobox border-alpha=0 alpha=1.0 top=-230 left=-278 ! videomixer name=mix ! ffmpegcolorspace ! autovideosink mix. rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,width=352,height=288,framerate=(fraction)25/1" ! ffmpegcolorspace ! mix.

Attention de bien fixer les framerates (videorate ou videoscale + capsfilter), car videomixer (le plugin qui s'occupe de faire le mixage vidéo) semble assez sensible sur ce point.

Streaming vers une autre machine

Nous allons maintenant voir comment transcoder le flux vidéo d'une caméra IP pour le diffuser (streamer vers une autre machine).

La description du pipeline du PC1 est la suivante:

• récupérer le flux MPEG4/RTSP de la caméra
• réencodage en Theora (à 250 Kbps)
• diffusion en UDP vers le PC2

puis celle du PC2:

• récupérer de flux Theora/UDP venant du PC1
• décodage Theora
• affichage de la vidéo

et les commandes correspondantes, sur le PC2 (il faut lancer cette commande en premier):

gst-launch -v udpsrc port=1234 ! theoradec ! autovideosink

puis sur le PC1:

gst-launch rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)25/1" ! queue ! theoraenc bitrate=250 ! queue ! udpsink host=pc2 port=1234

En moyenne, le débit observé entre PC1 et PC2 est de l'ordre de 250 Kbps (conforme donc a ce que l'on a configuré dans le plugin theoraenc), on observe cependant des pics à 250 Kps+30%. La consommation de CPU est de l'ordre de 25% sur PC1 et de 5% sur PC2. La vidéo est recue de manière fluide sur le PC2. Là encore, il ne faut pas oublier de fixer le nombre d'images par seconde avec videorate + capsfilter.

L'avantage avec GStreamer, c'est qu'il intégre une liste de plugins assez impressionnante, il est alors facile de les insérer dans notre pipeline. Par exemple, si l'on souhaite reprendre l'exemple ci-dessus et y ajouter un texte en sur-impression (overlay), il suffit d'utiliser le plugin cairotextoverlay.

La commande sur le PC1 devient alors:

gst-launch-0.10 rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! queue ! cairotextoverlay text="Attention Tigrou !" shaded-background=true ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)25/1" ! queue ! theoraenc bitrate=250 ! queue ! udpsink host=pc2 port=1234

et le résultat sur PC2:

Pour conclure

Ce billet nous a permis de mettre le pied dans le monde passionnant du traitement des flux vidéo. Ce n'est qu'une introduction et la seule limite est votre imagination. Je vous rappelle que GStreamer peut être simplement intégré à vos applications grâce aux API disponibles. Si vous avez des questions et remarques sur le sujet, il existe une section spéciale dans le forum !

Installation du système FreeBSD

Robustesse et qualité de sa pile IP font du système FreeBSD un bon "hôte" pour notre serveur VPN. Afin de ne pas surcharger le serveur avec des logiciels inutiles, j'ai choisi l'installation minimale (développeur, comprenant les "ports") à partir du réseau (ISO 7.x-RELEASE-i386-bootonly).

Avant de commencer l'installation d'OpenVPN, il est préférable de s'assurer que notre système d'exploitation est à jour en suivant cette procédure.

Installation de OpenVPN

On commence par installer le port OpenVPN avec la commande suivante:

# pkg_add -r openvpn

On automatise le lancement en ajoutant la ligne suivante au fichier /etc/rc.conf:

openvpn_enable="YES"

Configuration du serveur OpenVPN

OpenVPN permet la création de tunnel VPN de type SSL. Il faut donc que votre serveur puisse gérer des clès de chiffrement. Les étapes à suivre sont les suivantes:

# vi openssl.cnf
dir = /etc/ssl/CA
default_days = 3650 # Valable 10 ans...
default_bits  = 2048 # Clès de 2048 bits
countryName_default = FR
stateOrProvinceName_default = PACA
localityName_default = Valbonne
0.organizationName_default = MaBoite
commonName_default = mondomaine.com
emailAddress_default = contact@mondomaine.com

# mkdir /etc/ssl/CA

# cd /etc/ssl/CA
# mkdir certs
# mkdir crls
# mkdir newcerts
# mkdir private
# touch index.txt
# echo 01 > serial
# echo 01 > crlnumber
# openssl req -nodes -new -x509 -keyout private/cakey.pem -out cacert.pem -days 3650
> Laisser les options par défaut

A ce stade, on doit avoir notre clés créé dans le fichier private/cakey.pem:

# ls /etc/ssl/CA/private
cakey.pem

On génère ensuite le fichier de révocation:

# cd /etc/ssl/CA
# openssl ca -gencrl -out crls/crl.pem
# chown root:nobody crls/crl.pem

On passe maintenant à la génération de notre certificat pour notre serveur VPN:

# cd /etc/ssl/CA/certs
# openssl req -nodes -new \
-keyout vpn.mondomaine.com.key \
-out vpn.mondomaine.com.csr
> Laisser les options par défaut puis entrer un mot de passe
# chmod 600 /etc/ssl/CA/certs/vpn.mondomaine.com.key

Puis on le signe:

# openssl ca -out al-vpn1.alcasat.net.crt
\-in al-vpn1.alcasat.net.csr
\-policy policy_anything

Enfin on génère les paramètres Diffie-Hellman pour l'échange des clés:

# openssl dhparam -out dh2048.pem 2048

Pour configurer OpenVPN, nous allons nous baser sur une configuration d'exemple fournie par OpenVPN dans le fichier /usr/local/share/doc/openvpn/sample-config-files/server.conf.

# mkdir /usr/local/etc/openvpn/
# cp /usr/local/share/doc/openvpn/sample-config-files/server.conf \
/usr/local/etc/openvpn/openvpn.conf

Puis éditer le fichier /usr/local/etc/openvpn/openvpn.conf en adaptant la configuration à votre réseau.

Voici ma configuration:

et le fichier .conf correspondant:

port 1194
proto udp
dev tun

ca /etc/ssl/CA/cacert.pem
cert /etc/ssl/CA/certs/al-vpn1.alcasat.net.crt
key /etc/ssl/CA/certs/al-vpn1.alcasat.net.key
crl-verify /etc/ssl/CA/crls/crl.pem
dh /etc/ssl/CA/certs/dh2048.pem

server 192.168.40.0 255.255.255.0

ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"

keepalive 10 120

cipher BF-CBC
comp-lzo

user nobody
group nobody

persist-key
persist-tun

status openvpn-status.log
verb 6
mute 20

Lancement du serveur OpenVPN

On utilise le script système:

# /usr/local/etc/rc.d/openvpn start

Pour vérifier que le tunnel VPN est prêt à accueillir des clients, on peut vérifier que le preocess openvpn est bien lancé et que l'interface tun0 est bien présente:

# /usr/local/etc/rc.d/openvpn status
openvpn is running as pid 2212.

# ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
inet 192.168.40.1 --> 192.168.40.2 netmask 0xffffffff
Opened by PID 2207

Pour relancer le serveur (en cas de changement de configuration):

# /usr/local/etc/rc.d/openvpn restart

Pour arrêter le serveur:

# /usr/local/etc/rc.d/openvpn stop

La consultation des logs peut être faire via la commande:

# tail -f /var/log/messages | grep openvpn

Configuration de votre réseau

Si votre réseau hébergeant le serveur VPN comporte des routeurs il faut leur ajouter la route suivante (exemple donnée pour un ajout de route sur un routeur FreeBSD):

# route add -net 192.168.40.0/24 @IP-SERVEUR-VPN

Configuration d'un client Linux

A partir du serveur VPN, on génére les clés pour le nouveau client:

# cd /etc/ssl/CA/certs
# openssl req -nodes -new -keyout vpn-nicolargo.key -out vpn-nicolargo.csr
Generating a 2048 bit RSA private key
...............................................+++
...................+++
writing new private key to 'vpn-nicolargo.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [PACA]:
Locality Name (eg, city) [Valbonne]:
Organization Name (eg, company) [MaBoite]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) [mondomaine.com]:vpn-nicolargo.mondomaine.com
Email Address [contact@mondomaine.com]:monadresse@mondomaine.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:monpassword
An optional company name []:

Il faut changer le fichier /etc/ssl/CA/serial (incrémenter la valeur de 1).

# echo 02 > /etc/ssl/CA/serial

Puis signer le certificat:

# openssl ca -out vpn-nicolargo.crt \
-in vpn-nicolargo.csr -policy policy_anything

Sur la machine cliente, on copie les 3 fichiers ainsi que la clés serveur cacert.pem dans le répertoire /etc/ssl/certs (à créer si il n'existe pas).

On doit se retrouver avec nos 4 fichiers:

# ls /etc/ssl/certs/*
/etc/ssl/certs/cacert.pem
/etc/ssl/certs/vpn-nicolargo.crt
/etc/ssl/certs/vpn-nicolargo.csr
/etc/ssl/certs/vpn-nicolargo.key

On protége nos fichiers:

# groupdadd nobody
# chown root:nobody /etc/ssl/certs/cacert.pem
# chown root:nobody /etc/ssl/certs/vpn-nicolargo.*
# chmod 600 /etc/ssl/certs/vpn-nicolargo.key

Après installation d'OpenVPN sur votre machine cliente, on le configure en créant le fichier client.conf dans le répertoire /etc/openvpn/ (sous GNU/Linux Ubuntu):

# sudo vi /etc/openvpn/client.conf
client
dev tun
proto udp
remote al-vpn1.alcasat.net 1194
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/ssl/certs/cacert.pem
cert /etc/ssl/certs/vpn-hennionn.crt
key /etc/ssl/certs/vpn-hennionn.key
cipher BF-CBC
comp-lzo
verb 6
mute 20

Lancement du client OpenVPN Linux

Pour monter le VPN entre notre client et le serveur, on utilise le script système (sous GNU/Linux Ubuntu):

# sudo /etc/init.d/openvpn start client
* Starting VPN 'client' [OK]

L'arrêt se fera tout aussi simplement:

# sudo /etc/init.d/openvpn stop client

* Stopping VPN 'client' [OK]

Par défaut, au démarrage de la machine, OpenVPN va lancer tout les tunnels VPN dont il trouve une configuration dans le répertoire /etc/openvpn/. Si vous souhaitez désactiver cette fonction et monter vous même le VPN à la main, il faut éditer le fichier /etc/default/openvpn (sous GNU/Linux Ubuntu) et décommenter la ligne suivante:

AUTOSTART="none"

Pour conclure...

Il est possible de configurer d'autres clients en suivant la même procédure, le tunnel VPN étant routé, il peut accueillir plusieurs utilisateurs en même temps.

Des clients OpenVPN avec interface graphique sont également disponibles sous Windows et Mac OS X.

Quelques sources utiles à la rédaction de ce billet:

• Le How-To du site officiel (en)
• OpenVPN - Creating a routed VPN - FreeBSD Diary (en)
• Setting up routed OpenVPN in FreeBSD - Wiki Section6 (en)
• Basic of using OpenSSL - Wiki Section 6 (en)
  

Nous allons voir dans ce billet comment fonctionne ce protocole et comment transformer votre routeur/firewall PF FreeBSD en un daemon NAT-PMP.

C'est quoi NAT-PMP ?

NAT-PMP est un protocole basée sur le protocole Bonjour. Ce dernier utilise des trames UDP sur le port 5351 qui sont envoyé vers l'adresse de la passerelle par défaut de votre réseau.

Il permettant à une application de:

• récupérer son adresse IP publique (comment le PC va être vu sur Internet)
• ajouter une règle de NAT PF (ou IPFW) sur le routeur

Si l'adresse publique de la passerelle par défaut change, une alerte au format multicast (adresse 224.0.0.1 sur le port 5351) sera envoyée sur le réseau. Elle contiendra en donnée la nouvelle adresse.

Installation du daemon sur FreeBSD

Le daemon en question s'appelle minipnpd et est présent dans les ports de FreeBSD (/usr/ports/net/miniupnpd).

L'installation est classique:

portinstall net/miniupnpd

Il faut également ajouter les règles suivantes dans votre fichier de configuration PF (/etc/pf.conf par défaut):

# NAT section
# UPnPd rdr anchor
rdr-anchor "miniupnpd"

# Rules section
# uPnPd rule anchor
anchor "miniupnpd"

puis relancer les règles PF:

pfctl -f /etc/pf.conf

et enfin ajouter la ligne suivante dans votre fichier /etc/rc.conf:

miniupnpd_enable="YES"

La configuration doit se faire par un fichier /usr/local/etc/miniupnpd.conf. Vous pouvez utiliser le template suivant (à adapter à votre réseau):

# WAN network interface
ext_ifname=em0
# if the WAN interface has several IP addresses, you
# can specify the one to use below
#ext_ip=

# there can be multiple listening ips for receiving SSDP traffic.
# the 1st IP is also used for UPnP Soap traffic.
listening_ip=192.168.0.254
port=5555

# bitrates reported by daemon in bits per second
bitrate_up=131072
bitrate_down=524288

# default presentation url is http address on port 80
#presentation_url=

# report system uptime instead of daemon uptime
system_uptime=yes

# notify interval in seconds default is 30 seconds.
#notify_interval=240

# log packets in pf
#packet_log=no

# uuid : generated by the install a new one can be created with
# uuidgen
uuid=%%UUID%%

# UPnP permission rules
# (allow|deny) (external port range) ip/mask (internal port range)
# A port range is <min port>-<max port> or <port> if there is only
# one port in the range.
# ip/mask format must be nn.nn.nn.nn/nn
allow 1024-65535 192.168.0.0/24 1024-65535
deny 0-65535 0.0.0.0/0 0-65535

Pour lancer le daemon, il faut lancer la commande suivante:

/usr/local/etc/rc.d/miniupnpd start

Pour tester

Le plus simple est d'utiliser une des applications compatibles UPnP (voir liste dans le Wiki) ou bien d'utiliser le client en ligne de commande miniupnpc (compilable sous Linux, BSD, Mac OS X et Windows...).

Conclusion

Bien sûr ce daemon peut présenter un trou de sécurité assez important (possibilité d'ajouter des règles sur votre Firewall), il faut donc prendre toutes les précautions nécessaires sur les réseaux sensibles (notamment au niveau de la configuration de la section UPnP permission rules).

Cette nouvelle version apporte un meilleur control au niveau du tag permettant de faire les tests en IPv6 et surtout la possibilité (via l'option "-s") de fixer le champs ToS des paquets IPv4 (très utile pour tester votre configuration QoS).

La page officielle de SJitter est ici, la forge là.

Nous allons utiliser le module Net:Netem des noyaux Linux 2.6 pour simuler les caractéristiques suivantes:

• Bande passante
• Délai de transit
• Perte de paquet
• Duplication de paquet
• Re-arrangement de paquet

La configuration de ce module se fait via la commande en ligne tc.

Simuler un délai de transit constant

Le délai est le temps de transit réseau d'un paquet IP. Il dépend de pas mal de paramètres (traversé des équipements, taille des buffers et distance physique entre les deux points du réseau). Nous allons utiliser la commande delay qui va simuler un délai de transit de X ms sur tout les paquets IP sortant de l'interface réseau. On va utiliser la commande "ping" pour vérifier que tout fonctionne comme prévu.

Test du réseau avant la commande tc:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=0.290 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=0.204 ms

On simule un délai de 40 ms sur tout les paquets sortant (soit environ le délais sur une liaison ADSL):

sudo tc qdisc add dev eth0 root netem delay 40ms

Test du réseau après la commande tc:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=40 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=40 ms

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

On vérifie que l'on retombe bien sur les caractéristiques normale du réseau:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=0.218 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=0.209 ms

Simuler un délai de transit "normal"

Sur un réseau WAN, le délai de transit n'est jamais constant à travers le temps (surtout pour des liaisons de type Internet). Nous allons donc modifier la commande précédente pour intégrer une variation de délai (gigue de +/- 10ms) sur les paquets sortant:

sudo tc qdisc add dev eth0 root netem delay 40ms 10ms distribution normal

On obtient les caractéristiques suivantes:

$ ping 192.168.29.1PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=36.9 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=50.5 ms
64 bytes from 192.168.29.1: icmp_seq=3 ttl=64 time=33.1 ms
64 bytes from 192.168.29.1: icmp_seq=4 ttl=64 time=43.1 ms
64 bytes from 192.168.29.1: icmp_seq=5 ttl=64 time=32.5 ms
64 bytes from 192.168.29.1: icmp_seq=6 ttl=64 time=23.6 ms
...

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler une bande passante limite

Cette fonction ne fait pas partie de Netem mais utilise tout de même la commande tc pour se configurer.

Avant de commencer nous allons tester la capacité de notre réseau LAN avec la commande IPerf (à lancer en mode serveur UDP sur votre machine cible, 192.168.29.1 dans mon cas):

$ iperf -c 192.168.29.1 -u -b 10M
------------------------------------------------------------
Client connecting to 192.168.29.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
------------------------------------------------------------
[  3] local 192.168.29.222 port 47532 connected with 192.168.29.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec
[  3] Sent 8505 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec 0.008 ms    0/ 8505 (0%)

On a donc bien un débit de 10 Mbps.

On commence par créer la racine de l'arbre des classes (avec une simulation de délai "normal" de 40ms):

sudo tc qdisc add dev eth0 root handle 1:0 netem delay 40ms 10ms distribution normal

Puis on y ajoute un "tuyau" limitant le trafic sortant à 512 Kbps:

sudo tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 512kbit buffer 3200 limit 6000

On re-teste notre réseau:

$ iperf -c 192.168.29.1 -u -b 10M
------------------------------------------------------------
Client connecting to 192.168.29.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
------------------------------------------------------------
[  3] local 192.168.29.222 port 57589 connected with 192.168.29.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec
[  3] Sent 8505 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.3 sec    609 KBytes    486 Kbits/sec 14.351 ms 8081/ 8505 (95%)

On arrive bien à limiter le débit réseau sortant à 500 Kbps (un peu moins pour mon test).

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler une perte de paquets

La perte de paquets (ou "packet loss" dans la langue de Shakespeare) peut être simulé par Netem par la commande loss. Dans l'exemple suivant, nous allons simuler un lien WAN avec une perte de 0.1% des paquets sortant (soit 1 paquet perdu sur 1000 envoyé) avec un corrélation de 25% sur la probabilité que 2 paquets soit perdu de suite.

sudo tc qdisc add dev eth0 root netem loss 0.1% 25%

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler d'autres paramètres réseau

Il est également possible de simuler la duplication de paquets (commande duplicate), la corruption de paquets (commande corrupt) et le re-arrangement des paquets (commande gap).

Simuler également les paquets entrants

Imaginons que l'on veuille simuler une liaison de type ADSL, cette liaison est asymétrique en terme de débit. Il faut donc pouvoir simuler de manière différente le débit entrant (DOWNLOAD) du débit sortant (UPLOAD). Pour cela, il faut passer par la déclaration d'une interface réseau virtuelle (ifb) dans laquelle nous allons re-router les paquets entrants. Nous appliquerons nos paramètres réseau de simulation sur cette nouvelle interface.

Commençons par créer cette interface virtuelle:

# modprobe ifb
# ip link set dev ifb0 up
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

Puis appliquons un délai de 40ms comme vu dans le chapitre précédant:

# tc qdisc add dev ifb0 root netem delay 40ms 10ms distribution normal

Un exemple complet: simulation d'une liaison ADSL

Voici un script Shell (bash) permettant de mettre en place une simulation de type liaison ADSL sur votre réseau local:

#!/bin/bash
#
# limitbw.sh
# Nicolargo - 2009
#

# Nom de l'interface ou l'on doit faire la simulation
IF=eth0

# Liaison sortante (UPLOAD)

# Debit sortant
BWU=768kbit
# Délai de transit sortant
DELAYU=20ms
# % de paquets perdus sortant
LOSSU=0.01%

# Liaison entrante (DOWNLOAD)

# Debit entrant
BWD=2mbit
# Délai de transit entrant
DELAYD=20ms
# % de paquets perdus entrant
LOSSD=0.01%

start() {

# Liaison entrante

modprobe ifb
ip link set dev ifb0 up
tc qdisc add dev $IF ingress
tc filter add dev $IF parent ffff: \
protocol ip u32 match u32 0 0 flowid 1:1 \
action mirred egress redirect dev ifb0

tc qdisc add dev ifb0 root handle 1:0 \
netem delay $DELAYD 10ms distribution normal \
loss $LOSSD 25%
tc qdisc add dev ifb0 parent 1:1 handle 10: \
tbf rate $BWD buffer 3200 limit 6000

# Liaison sortante

tc qdisc add dev $IF root handle 2:0 \
netem delay $DELAYU 10ms distribution normal \
loss $LOSSU 25%
tc qdisc add dev $IF parent 2:1 handle 10: \
tbf rate $BWU buffer 3200 limit 6000

}

stop() {

tc qdisc del dev ifb0 root

tc qdisc del dev $IF root

# ip link set dev ifb0 down

}

restart() {

stop
sleep 1
start

}

show() {

echo "Liaison entrante"

tc -s qdisc ls dev ifb0

echo "Liaison sortante"

tc -s qdisc ls dev $IF

}

case "$1" in

start)

echo -n "Starting WAN simul: "
start
echo "done"
;;

stop)

echo -n "Stopping WAN simul: "
stop
echo "done"
;;

restart)

echo -n "Restarting WAN simul: "
restart
echo "done"
;;

show)

echo "WAN simul status for $IF:"
show
echo ""
;;

*)

echo "Usage: $0 {start|stop|restart|show}"
;;

esac

exit 0

Bonne simulation