Catégories
Open-source Reseau

Tunnel HTTP pour faire du SSH depuis le bureau

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 ! 🙂

Catégories
Open-source Reseau

Compilation de VnStat sous Ubuntu/Debian

Hier, je vous ai parlé de VnStat, un outil pour surveiller le débit de vos interfaces réseaux. J’avais fait mes tests sous FreeBSD qui inclu la dernière version de VnStat (1.10) dans ses packages. Ce n’est pas encore le cas des systèmes Linux qui proposent la version 1.6. Hors cette version ne permet pas l’utilisation de l’utilitaire VnStati pour générer les images.

Voici donc dans ce billet une procédure très simple pour installer la version 1.10 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.10.tar.gz

On décompresse et on compile:

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

Puis on installe sur notre système:

sudo make install

Et voili…

Catégories
Nagios Open-source Reseau

VNStat surveille votre bande passante

Obsolete
Merci de consulter ce billet plus récent.

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

Sous FreeBSD:

# pkg_add -r vnstat

Puis ajouter la ligne suivant dans votre crontab (seulement sous FreeBSD):

*/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:

# vnstati -h

Statistiques journalières avec l’option -d:

# vnstati -d

Statistiques mensuelle avec l’option -m:

# vnstati -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).

Catégories
Hardware Open-source Reseau Systeme

GStreamer aime les caméras IP Axis

Si vous lisez régulièrement ce blog, vous savez que je m’intéresse au FrameWork multimédia GStreamer (cliquez ici pour voir la liste des billets sur le sujet). Nous allons poursuivre la découverte de cette superbe trousse à outil multimédia en l’appliquant sur la récupération et l’exploitation de flux vidéo venant de caméras IP. Nous nous focaliserons ici sur les caméras IP AXIS, non pas que j’ai des actions dans cette société mais il faut avouer que leurs caméras sont de très bonne qualité et l’accès aux flux vidéos assez simple.

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:

La configuration de cette caméra (cam01) est la suivante:

Format CIF
Compression 50%
Frame rate: 25 images/s

Configuration du PC1:

OS: GNU/Linux Debian 5.0 + Gstreamer 0.10.19-3
Hardware: Pentium Quad core CPU 2.8 Ghz + 4 Go RAM

Configuration du PC2:

OS: GNU/Linux Ubuntu 8.10 + Gstreamer 0.10.21-4
Hardware: Pentium Dual core CPU 3.0 Ghz + 512 Mo RAM

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 !

Catégories
Open-source Reseau

Installation d’un serveur VPN sous FreeBSD

Le but de ce billet est de détailler l’installation d’un serveur VPN routé de type SSL sur un système FreeBSD 7. Nous utiliserons pour cela le logiciel libre OpenVPN (licence GPL v2).

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/CA/cacert.pem
chown root:nobody /etc/ssl/CA/certs/vpn-nicolargo.*
chmod 600 /etc/ssl/CA/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:

Catégories
Open-source Reseau Web

Installation serveur NAT-PMP sous FreeBSD

MiniUPnP est une implémentation libre du protocole NAT-PMP. Développé par Apple, ce successeur de UPnP IGD permet de configurer automatique et à la demande des applications des règles de NAT sur votre routeur d’accès. Free vient d’ajouter cette fonction sur le firmware des Freebox.

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).

Catégories
Open-source Reseau

SJitter version 0.18

Grâce à la contribution de Thierry Legras, voici une nouvelle version de SJitter, mon outil en ligne de commande permettant de tester un réseau, notamment au niveau débit, délai et gigue. SJitter est disponible sous Linux, BSD, Mac OS X et Windows (via cygwin).

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 .

Catégories
Open-source Reseau

Simuler un lien WAN sous Linux

Il peut être utile, dans le cadre de tests applicatifs, de simuler sur votre réseau local (LAN), les caractéristiques d’une liaison distante (WAN). En effet, vos applications peuvent très bien fonctionner sur un réseau LAN et devenir inexploitable sur des liaisons WAN.

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 😉

Catégories
Open-source Reseau

Outil pour la mesure de la QoS sur les réseaux IP

La qualité de service (QoS pour « Quality of service ») est la capacité à véhiculer dans de bonnes conditions un type de trafic donné en termes de disponibilité, débit, délai de transmission, gigue, taux de perte de paquets… (source Wiki)

La notion de qualité de service est une notion subjective, de ressenti utilisateur face à l’utilisation d’un système informatique. Il n’est pas trivial de mesurer cette QoS. Nous allons dans ce billet aborder quelques outils libres permettant d’obtenir des indicateurs chiffrés en nous focalisant sur la problématique des réseaux IP.

Ou faire les mesures ?

Première question à se poser quand on doit faire ce genre de mesure. La réponse dépend bien sûr de votre architecture. Souvent, l’on souhaite vérifier la QoS sur une liaison WAN( par exemple un liaison de type _DSL vers votre FAI). Dans ce cas précis, la mesure pourra être faite sur votre routeur d’accès, c’est à dire juste avant la liaison. En effet, celà permet de prendre en compte tous les flux de votre réseau. Il faut pour celà disposer d’un routeur d’accès sur lequel on peut installer les outils de mesures (par exemple un routeur/firewall basé sous Linux ou FreeBSD). Si ce n’est pas le cas, il est toujours possible de mettre un PC (sous Linux) en coupure entre votre switch réseau et votre routeur/modem.

Quoi mesurer ?

Pour un réseau en fonctionnement (c’est à dire que l’on écarte la disponibilité), on peut distinguer quatres grandes variables:

  • le débit: c’est la bande passante utilisé par un flux. Celle-ci peut être constante ou variable.
  • le délai de transit des paquets IP: dans un réseau IP, les données sont segmentées en paquets. Le délai de transit est le temps mis par uhn paquet pour aller d’un point A vers un point B.
  • la gigue dans un flux de paquets IP: c’est la variation du délai de transit entre plusieurs paquets IP. Ce paramètre est très important pour les applications de voix sur IP (VoIP) car les codecs de compression de la voix sont très sensibles à la gigue.
  • la perte de paquets: c’est le pourcentage de paquets IP perdus sur le réseau.

Comment tester ?

Plusieurs solutions sont possibles. La première consiste à utiliser les logiciels qu l’on souhaites tester sur son réseau. On peut le faire de manière manuelle ou automatique (via des scripts par exemple). L’important est de générer des flux qui soient représentatifs de l’utilisation standard de votre réseau.

Une autre solution est de simuler les flux à l’aide d’un outil comme Iperf qui est capable de générer un flux IP finement paramètrable sur le réseau. Par finement on entend:

  • Protocole: UDP, TCP, ICMP…
  • Port réseau
  • Taille des paquets de données
  • Débit
  • Temps
  • Tag du champ DSCP (dans le cadre d’un réseau compatible Diffserv)

Pour vous aider dans l’utilisation de ce logiciel, vous pouvez lire les billets suivants:

Comment mesurer ?

Iperf permet de générer en sortie un rapport sur quelques uns de ces paramètres, notamment le débit (moyen, minimum et maximum) et le délai. L’idée générale et de faire un plan de test avec les différentes configurations possible en terme d’utilisation et de QoS et de regarder les valeurs obtenues en sorties. En complément de Iperf, vous pouvez utiliser SJitter pour la mesure de la gigue réseau.

En complément de IPerf, il peut être utile d’utiliser un logiciel de capture réseau tel que Wireshark. En effet, grâce à ce dernier, vous pouvez sauvegarder les flux et les filter/analyser avec les nombreux modules disponibles.

Voici un tableau, basée sur mon expérience personnelle, des valeurs à prendre en compte lors de vos mesures.


Et vous quel est votre expérience sur le sujet ? Utiliser vous d’autres logiciels libres pour mesurer les performances de votre réseau ?

Catégories
Blog Open-source Reseau Systeme

Petites stats sur le forum

Après un mois d’existence, le forum du Blog de Nicolargo se porte bien. Quelques chiffres:

  • 69 utilisateurs déclarées
  • 70 question posées
  • 426 réponses
  • quelques utilisateurs très actifs (Suikox, Carnage76, Raptor45, Megax…)
  • plus de 100 pages vues par jours

Beaucoup de sujets abordés autour de Nagios, Centreon et la supervision réseau, mais n’oubliez pas que le but de ce forum est de partager ses idées sur tout les sujets du blog 😉

Pour vous inscrire et participer activement à la vie open-source, c’est par ici !