Catégorie : Reseau

Catégories
Open-source Planet-libre Reseau Web

Installation d’un serveur OpenVPN sous Debian/Ubuntu

Dernière mise à jour de ce billet: Le 20 octobre 2013.

Sur la longue route menant à la protection de la vie privée sur Internet, on entend de plus en plus parler des réseaux privés virtuels (VPN pour les geek). Cette technique permet la création d’une liaison chiffrée entre votre machine et un serveur hébergé sur Internet (par exemple chez un fournisseur d’accès se trouvant en France ou à l’étranger). Tous vos accès à Internet seront alors vus à partir de l’adresse IP de ce serveur VPN et non plus par celle de votre machine.

Avec la généralisation des systèmes de surveillance mis en place pour les lois de type Hadopi&Co, les offres de VPN payantes ont tendances à fleurir en ce moment sur le marché.

Nous allons dans ce billet voir comment installer et configurer son propre serveur VPN sous Ubuntu basée sur OpenVPN, une solution libre et compatible avec des clients multi-OS.

Toute petite introduction à OpenVPN

OpenVPN n’est pas un VPN IPSec. C’est un VPN SSL se basant sur la création d’un tunnel IP (UDP ou TCP au choix) authentifié et chiffré avec la bibliothèque OpenSSL.

Quelques avantages des tunnels VPN SSL:

  • Facilité pour passer les réseaux NATés (pas de configuration à faire)
  • Logiciel clients disponibles sur GNU/Linux, BSD, Windows et Mac OS X.

Installation du serveur OpenVPN

Nous allons détailler l’installation du serveur OpenVPN sur une distribution Ubuntu Server LTS 10.04 (mais la procédure doit être la même sur Debian like).

On commence par installer OpenVPN à partir des dépôts officiels:

sudo aptitude install openvpn

On copie ensuite les fichiers de configurations:

sudo mkdir /etc/openvpn/easy-rsa/

sudo cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/

sudo chown -R $USER /etc/openvpn/easy-rsa/

Configuration du serveur OpenVPN

A l’aide des scripts installés dans le répertoire /etc/openvpn/easy-rsa/ nous allons configurer OpenVPN pour utiliser une authentification par clés et certificats.

On commence par éditer le fichier /etc/openvpn/easy-rsa/vars:

export KEY_COUNTRY= »FR »

export KEY_PROVINCE= »06″

export KEY_CITY= »Nissa »

export KEY_ORG= »nicolargo.com »

export KEY_EMAIL= »dtc@hadopi.fr »

Ensuite on lance la séquence suivante qui va générer les clés (.key) et les certificats (.crt):

cd /etc/openvpn/easy-rsa/

source vars

./clean-all

./build-dh

./pkitool –initca

./pkitool –server server

sudo openvpn –genkey –secret keys/ta.key

On copie ensuite les clés et les certificats utiles pour le serveur dans le répertoire /etc/openvpn/:

sudo cp keys/ca.crt keys/ta.key keys/server.crt keys/server.key keys/dh1024.pem /etc/openvpn/

Puis on génère un répertoire /etc/openvpn/jail dans lequel le processus OpenVPN sera chrooté (afin de limiter les dégâts en cas de faille dans OpenVPN) puis un autre répertoire (/etc/openvpn/clientconf) qui contiendra la configuration des clients:

sudo mkdir /etc/openvpn/jail

sudo mkdir /etc/openvpn/clientconf

Enfin on créé le fichier de configuration /etc/openvpn/server.conf:

# Serveur TCP/443

mode server

proto tcp

port 443

dev tun

# Cles et certificats

ca ca.crt

cert server.crt

key server.key

dh dh1024.pem

tls-auth ta.key 1

key-direction 0

cipher AES-256-CBC

# Reseau

server 10.8.0.0 255.255.255.0

push « redirect-gateway def1 bypass-dhcp »

push « dhcp-option DNS 208.67.222.222 »

push « dhcp-option DNS 208.67.220.220 »

keepalive 10 120

# Securite

user nobody

group nogroup

chroot /etc/openvpn/jail

persist-key

persist-tun

comp-lzo

# Log

verb 3

mute 20

status openvpn-status.log

; log-append /var/log/openvpn.log

Ce fichier permet de créer un serveur VPN SSL routé basée sur le protocole TCP et utilisant le port HTTPS (443) enfin de maximiser sont accessibilité depuis des réseaux sécurisés par des Firewalls. Les clients obtiendrons une nouvelle adresse IP dans le range 10.8.0.0/24.

On teste la configuration en saisissant la commande suivante:

cd /etc/openvpn

sudo openvpn server.conf

On doit obtenir les messages suivants:

Si le serveur démarre correctement, on peut terminer la configuration sur serveur OpenVPN en décommentant la dernière ligne du fichier /etc/openvpn/server.conf :

log-append /var/log/openvpn.log

On lance le serveur avec la commande:

sudo /etc/init.d/openvpn start

A ce stade les machines clientes vont pouvoir se connecter au serveur VPN. Par contre impossible d’aller plus loin que ce dernier car l’adresse 10.8.0.x ne sera par routée en dehors de votre serveur. Il faut donc configurer le serveur pour qu’il joue le rôle de routeur entre l’interface VPN (tun0) et l’interface physique (eth0) et de NATeur entre les adresses en 10.8.0.x et son adresse IP réelle.

Configuration du routage:

sudo sh -c ‘echo 1 > /proc/sys/net/ipv4/ip_forward’

Pour rendre ce paramètrage de routage permanant (même après un reboot), il faut ajouter la ligne suivante au fichier /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Puis configuration d’IpTables (si utilisé sur votre serveur) :

# règles obligatoires pour ouvrir déverrouiller l’accès :

sudo iptables -I FORWARD -i tun0 -j ACCEPT

sudo iptables -I FORWARD -o tun0 -j ACCEPT

sudo iptables -I OUTPUT -o tun0 -j ACCEPT

# autres règles : Translation d’adresses

sudo iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

sudo iptables -t nat -A POSTROUTING -s 10.8.0.2/24 -o eth0 -j MASQUERADE

Pour rendre cette règle de NAT persistante après un reboot de votre serveur, il faut commencer par créer un script de chargement de règles de Firewall (ou utiliser  un script existant):

sudo sh -c « iptables-save > /etc/iptables.rules »

Puis éditer votre fichier /etc/network/interfaces pour y ajouter la ligne suivante après la définition de votre interface réseau principale (« iface eth0 inet… » par exemple):

pre-up iptables-restore < /etc/iptables.rules

Le serveur est maintenant prêt à accueillir les clients. Nous allons donc voir dans le chapitre suivant comment déclaration un client sur le serveur.

Création d’un compte client OpenVPN

Imaginons que l’on veuille créer une clés pour le client « pcportablenicolargo » (c’est un exemple :)), alors il suffit de saisir les commandes suivantes sur le serveur:

cd /etc/openvpn/easy-rsa

source vars

./build-key pcportablenicolargo

Note: si vous souhaitez protéger l’accès à vos clés par un mot de passe (c’est à dire qu’un mot de passe sera demandé à la monté du tunnel VPN), il faut utiliser la commande ./build-key-pass en lieu et place de ./buil-key.

Le script ./build-key va générer 3 fichiers dans le répertoire /etc/openvpn/easy-rsa/keys:

  • pcportablenicolargo.crt: Certificat pour le client
  • pcportablenicolargo.csr: Certificat à garder sur le serveur
  • pcportablenicolargo.key: Clés pour le client

On copie les fichiers nécessaires un sous répertoire du répertoire /etc/openvpn/clientconf/ préalablement créé:

sudo mkdir /etc/openvpn/clientconf/pcportablenicolargo/

sudo cp /etc/openvpn/ca.crt /etc/openvpn/ta.key keys/pcportablenicolargo.crt keys/pcportablenicolargo.key /etc/openvpn/clientconf/pcportablenicolargo/

On va ensuite dans le répertoire /etc/openvpn/clientconf/pcportablenicolargo/:

cd /etc/openvpn/clientconf/pcportablenicolargo/

Puis on créé le fichier client.conf (il faut remplacer A.B.C.D par l’adresse publique de votre serveur VPN que vous pouvez obtenir avec la commande « wget -qO- ifconfig.me/ip »):

# Client

client

dev tun

proto tcp-client

remote A.B.C.D 443

resolv-retry infinite

cipher AES-256-CBC

; client-config-dir ccd

# Cles

ca ca.crt

cert pcportablenicolargo.crt

key pcportablenicolargo.key

tls-auth ta.key 1

key-direction 1

# Securite

nobind

persist-key

persist-tun

comp-lzo

verb 3

Pour assurer la compatibilité avec le client Windows OpenVPN, on fait une copie du fichier client.conf vers client.ovpn:

sudo cp client.conf client.ovpn

On devrait ainsi avoir les fichiers suivants dans le répertoire /etc/openvpn/clientconf/pcportablenicolargo/:

  • ca.crt: Certificat du serveur
  • client.conf: Fichier de configuration du client OpenVPN (Linux, BSD, MacOS X)
  • client.ovpn: Fichier de configuration du client OpenVPN (Windows)
  • hennionn.crt: Certificat du client
  • hennionn.key: Clés du client
  • ta.key: Clés pour l’authentification

Il ne reste plus qu’à mettre ces fichiers dans une archive ZIP et de la transmettre sur le PC client:

sudo zip pcportablenicolargo.zip *.*

Update

Pour les plus fainéants, j’ai créé un script (dépôt source sous GitHub) permettant d’automatiser les étapes décrites dans ce paragraphe et donc de permettre simplement la déclaration d’un nouveau client VPN sur votre serveur:

/Update

Attribuer une adresse IP statique à un client VPN

Ce qui est expliqué dans ce chapitre est optionnel.

Pour des raisons de sécurité (par exemple l’application de filtre IP), il est parfois nécessaire d’affecter une adresse IP statique à un client VPN. Pour cela, il faut créer un répertoire qui va contenir les configurations statiques:

sudo mkdir /etc/openvpn/ccd

sudo ln -s /etc/openvpn/ccd /etc/openvpn/jail/ccd

Ensuite on édite à l’intérieur de ce répertoire un fichier correspondant au CNAME (X509) de l’utilisateur dont on veut rendre la configuration statique (par exemple pcportablenicolargo):

sudo vi /etc/openvpn/ccd/pcportablenicolargo

ifconfig-push 10.8.0.18 10.8.0.17

La syntaxe est la suivante: ifconfig-push @IPCLIENTTUNNELVPN @IPSERVEURTUNNELVPN.

Ainsi quand le client pcportablenicolargo se connectera au serveur VPN il obtiendra une adresse en 10.8.0.18. Le bout du tunnel VPN (coté serveur) sera lui en 10.8.0.17.

Note: A chaque modification de ce répertoire il faut en faire une copie vers le chroot (jail, à adapter à votre configuration):

cp /etc/openvpn/ccd/* /etc/openvpn/jail/ccd

On dé-commente la ligne suivante au niveau de la configuration du serveur (/etc/openvpn/server.conf):

client-config-dir ccd

Puis on relance le serveur:

sudo /etc/init.d/openvpn restart

Configuration d’un client OpenVPN sous Ubuntu

Les opérations suivantes sont à faire sur le PC client que l’on veut connecter au serveur VPN.

On part sur le principe ou le fichier pcportablenicolargo.zip a été téléchargé et dézippé dans le répertoire /etc/openvpn/pcportablenicolargo.

Gnome permet de configurer de manière graphique le client OpenVPN. Pour celà il faut ajouter les packages suivants sur sa distribution (Ubuntu Desktop 10.10 dans mon exemple):

sudo aptitude install openvpn resolvconf network-manager-openvpn-gnome

Il faut redémarrer la machine pour finaliser l’installation.

Déclaration du VPN sous Ubuntu

Ensuite on clique gauche sur l’icone réseau du Tableau de bord > Connexions VPN > Configurer le VPN.

On clique sur le bouton Importer.

On va dans le répertoire /etc/openvpn/pcportablenicolargo et on sélectionne le fichier client.conf.

La fenêtre suivante devrait s’afficher:

Il ne reste plus qu’à cliquer sur Appliquer.

Utilisation du VPN sous Ubuntu

Rien de très compliqué :). Si vous avez nommé votre déclaration de VPN Client alors, il suffit de cliquer gauche sur l’icone réseau du Tableau de bord > Connexions VPN > Client.

L’icône réseau du tableau de bord devrait se voir modifier (apparition d’un petit cadenas).

Pour ce déconnecter du VPN: Tableau de bord > Connexions VPN > Déconnecter le VPN.

Si vous avez une erreur lors de la connexion, vous pouvez essayer la méthode fournie par ce lecteur dans ce commentaire.

Configuration d’un client OpenVPN sous Windows

Update

Après quelques tests sous Windows XP, le client que je préconise ci dessous n’est vraiment pas concluant (impossible de se connecter au serveur une fois sur deux, pas de log…).

Je conseille donc l’utilisation d’une solution libre “OpenVPN  Windows” (à télécharger sur le site http://openvpn.net/index.php/open-source/downloads.html).

Une fois installé, il suffit de décompresser l’archive pcportablenicolargo.zip dans le répertoire C:\Programs Files\Openvpn\conf\ et de se connecter à partir du bouton qui se trouve dans la barre des taches.

/Update

On part sur le principe ou le fichier pcportablenicolargo.zip a été téléchargé et dézippé dans le répertoire c:\vpn\pcportablenicolargo.

On va utiliser le client OpenVPN pour Windows nommé « OpenVPN Acccess Server Windows client » téléchargeable sur le site suivant (il nécessite l’installation préalable du framework .NET 3.5 SP1, téléchargeable sur le même site).

Déclaration du VPN sous Windows

Une fois le logiciel téléchargé puis installé. Il suffit de cliquer sur le nouvel icône dans la barre des taches. La fenêtre suivante devrait apparaître. Il faut alors cliquer sur le bouton + pour ajouter une nouvelle connexion VPN.

Ensuite on sélectionne l’option d’importation locale (1) et on clique sur Import (2):

On sélectionne ensuite le fichier client.ovpn qui se trouve dans c:\vpn\pcportablenicolargo\:

On sauvegarde la configuration:

La nouvelle connexion VPN devrait apparaître dans la fenêtre principale:

Utilisation du VPN sous Windows

Il suffit de cliquer sur le nouvel icône dans la barre des taches.  Il faut alors cliquer sur le bouton correspondant à votre connexion VPN définie dans le paragraphe précédant.

Une fois la connexion établie, on a le message suivant:

Pour se déconnecter du VPN, il suffit de cliquer sur le bouton… « Disconnect » (bravo):

Surveiller les connexions VPN

Dans la configuration fournie en exemple, le processus OpenVPN server va écrire toute les minutes un état des clients connectés au serveur dans le fichier /etc/openvpn/openvpn-status.log.

On a, par exemple, les informations suivantes:

OpenVPN CLIENT LIST
Updated,Fri Jan 21 15:48:06 2011
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1,27.12.245.248:10086,306367,620864,Fri Jan 21 13:58:25 2011
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.10,client1,27.12.245.248:10086,Fri Jan 21 15:47:14 2011
GLOBAL STATS
Max bcast/mcast queue length,0
END

Sources:

Catégories
Open-source Planet-libre Reseau Systeme

Configurer VPNTunnel sous Ubuntu

VPNTunnel est un service VPN permettant d’accéder à Internet de manière complètement anonyme. Comme tous les services de VPN en ligne, il propose de créer une liaison chiffrée entre votre machine et des serveurs (ici localisés en Suède) qui ne garderons aucunes informations sur votre trafic. Nous allons voir dans ce billet comment configurer une machine sous Ubuntu pour la rendre invisible à Hadopi aux mouchards d’Internet…

Pourquoi VPNTunnel ?

Comme vous pouvez le voir sur leur site, ce service est payant (environ 5€ par mois, avec un tarif dégressif sur des abonnements longues durées). Ils existent des solutions gratuites (voir le Wiki de Korben sur le sujet), mais pour en avoir testé, aucune n’est à l’heure actuelle assez stable pour une utilisation quotidienne.

Parmi les offres payantes, VPNTunnel a pour moi deux avantages:

  • le prix
  • l’utilisation d’OpenVPN, une solution libre et parfaitement intégré à GNU/Linux

Enregistrement sur le site VPNTunnel

On commence par prendre un abonnement (par exemple sur 3 mois, soit 14€) en allant sur leur site.

On clique en suite sur Order (1), puis on sélectionne l’offre/la durée d’abonnement désirée  (2), le mode de paiement (par exemple Paypal !) puis le mail de contact sur lequel les login/password seront envoyés (3), puis le nom de login souhaité (4). On finalise en cliquant sur Continue.

Après quelques secondes (c’est beau l’internet…), vous devriez recevoir un mail avec votre compte:

Configuration de votre machine Ubuntu

Avec le compte reçu par mail, vous pouvez vous connecter sur l’interface d’administration de votre VPN (le formulaire d’authentification se trouve en haut à droite de leur site).

Pour celà on va dans le menu « Software » de l’interface d’administration:

On va ensuite récupérer les deux fichiers nécessaires à la configuration de notre VPN en cliquant sur les liens:

  • (1) Config: téléchargement des fichiers openvpn-XX.conf (fichier de configuration openvpn)
  • (2) Download VPN certificate: téléchargement du fichier ca-XX.crt (Certificat racine CA)

On installe les pré-requis système en saisissant les lignes suivantes dans un terminal:

sudo aptitude install openvpn resolvconf network-manager-openvpn

sudo mkdir /etc/openvpn/keys

Puis on copie les deux fichiers préalablement téléchargés dans les répertoires suivants:

sudo cp *.conf /etc/openvpn/

sudo cp *.crt /etc/openvpn/keys/

sudo ln -s /etc/openvpn/openvpn-NL.conf /etc/openvpn/openvpn.conf

Déclaration du VPN en utilisant le Network Manager

On commence par cliquer sur l’icone Network Manager > Connexion VPN > Configurer le VPN:

On clique ensuite sur le bouton Import:

On sélectionne ensuite le fichier de configuration OpenVPN: /etc/openvpn/openvpn.conf.

Puis on saisi les informations manquantes (nom du tunnel (1), login (2), password (3), fichier ca.crt (4)):

Le nouveau tunnel VPN devrait apparaître dans le Network Manager:

Connexion au VPN

Il suffit de cliquer sur l’icône Network Manager > Connexions VPN > Vpntunnel:

Si tout est ok (sinon lire le chapitre suivant…), l’icône Network Manager devrait se modifier et faire apparaître un cadenas:

Cela vous signale que vous êtes connecté à Vpntunnel et que vous pouvez commencer à surfer / télécharger de manière anonyme.

Pour le vérifier, le plus simple est de se rendre sur le site WhatsMyIp:

L’adresse 178.73.209.150 correspond bien à une adresse Suédoise comme nous l’indique un Whois:

# whois 172.73.209.150

inetnum: 178.73.192.0 – 178.73.255.255

netname: SE-PORTLANE-20100322

descr: Power och Random T-Lane AB

country: SE

org: ORG-PS39-RIPE

admin-c: PN1967-RIPE

tech-c: PN1967-RIPE

status: ALLOCATED PA

mnt-by: RIPE-NCC-HM-MNT

mnt-lower: MNT-PORTLANE

mnt-routes: MNT-PORTLANE

source: RIPE # Filtered

Et si cela ne marche pas ?

Si comme moi vous rencontrez le message suivant lors de la connexion à votre VPN:

« La connexion VPN a échoué car il n’y avait pas de secret VPN valides »

Il suffit de modifier le fichier /etc/dbus-1/system.d/nm-openvpn-service.conf en ajoutant:

<policy user= »at_console »>

<allow own= »org.freedesktop.NetworkManager.vpnc »/>

<allow send_destination= »org.freedesktop.NetworkManager.vpnc »/>

</policy>

Ce qui donne donc:

<busconfig>

<policy user= »root »>

<allow own= »org.freedesktop.NetworkManager.openvpn »/>

<allow send_destination= »org.freedesktop.NetworkManager.openvpn »/>

</policy>

<policy user= »at_console »>

<allow own= »org.freedesktop.NetworkManager.vpnc »/>

<allow send_destination= »org.freedesktop.NetworkManager.vpnc »/>

</policy>

<policy context= »default »>

<deny own= »org.freedesktop.NetworkManager.openvpn »/>

<deny send_destination= »org.freedesktop.NetworkManager.openvpn »/>

</policy>

</busconfig>

Après cette manipulation et un reboot tout devrait rentrer dans l’ordre.

Déconnexion du VPN

Pour se déconnecter du VPN, il suffit de cliquer sur Network Manager > Connexions VPN > Déconnecter le VPN:

Voilà un moyen efficace de sécuriser sa connexion Internet comme nous le demande Hadopi (peut être pas aussi efficace que le firewall OpenOffice > Libre Office, mais bon…).

Mon avis sur Vpntunnel

Je suis très surpris par la stabilité du VPN qui fonctionne 24/24 sans interruption depuis quelques jours.

Niveau performance, c’est indétectable lors des surfs. J’ai mesuré une baisse inférieure à 10% de débit lors de transferts de gros fichiers via FTP. Par contre on voit que les délais de transit passent d’environ 40ms de moyenne à plus de 90ms.

Complément de tests:

Je viens de faire des tests depuis chez moi (opérateur Free). Pour cela j’ai utilisé le service en choisissant un serveur cible en France (Paris).

Voici les résultats obtenus tout d’abord sans le VPN:

Puis avec:

On obtient donc:

  • une perte de 10% sur le download
  • une perte de 7% sur l’upload
  • une perte de 200% pour le délais de transit

 

Catégories
Open-source Planet-libre Reseau

Ziproxy re-compresse les images lors de vos surfs

Ziproxy est un proxy HTTP spécialisé dans la compression des données. Il permet par exemple de convertir les images des sites Web visités dans une qualité inférieure. Il permet également de compresser au format GZip les données de type pages HTML, CSS, JS ou autres.

Ce genre de proxy (qui ne fait pas de « caching ») a un sens dans les architectures réseau ou l’utilisateur final (l’utilisateur du navigateur Web) est relié à un site central (disposant d’une liaison haut-débit vers Internet) par une liaison de faible débit (par exemple accès VPN ou 3G pour les itinérants).

Nous allons donc dans ce billet installer, configurer (sans et avec Squid) puis tester un serveur Ziproxy.

Installation depuis les sources

La version disponible dans les dépôts Ubuntu/Debian est assez ancienne (2.7.2 au moment de l’écriture de ce billet). Nous allons donc compiler Ziproxy depuis les sources.

Avant de commencer, un certain nombre de pré-requis (notamment le support de JPEG 2000 et la création d’un utilisateur dédié pour lancer le daemon Ziproxy) doivent être installés:

sudo aptitude install libjasper-dev libgif-dev libungif4-dev libjpeg-dev libpng-dev libsasl2-dev zlib1g-dev

sudo adduser –shell /bin/noshell –no-create-home –disabled-login ziproxy

Compilation de la version 3.2.0 depuis les sources à récupérer sur le site Sourceforge.

tar jxvf ziproxy-3.2.0.tar.bz2

cd ziproxy-3.2.0

Compilation:

./configure –with-jasper

make

Installation:

sudo make install

Mise en place des fichiers de configuration et de lancement automatique:

sudo ln -s /usr/local/bin/ziproxy /usr/bin/ziproxy

sudo mkdir /etc/ziproxy

sudo mkdir /var/log/ziproxy

sudo chown ziproxy:ziproxy /var/log/ziproxy

sudo cp etc/ziproxy/ziproxy.conf /etc/ziproxy/

sudo cp etc/init.d/ziproxy /etc/init.d/

Le script de démarrage ayant été créé pour Fedora, voici le script que j’utilise sur un serveur Ubuntu Server 10.04:

#!/bin/bash

#

# Startup script for Ziproxy

#

# chkconfig: – 86 14

# description: Ziproxy

# Copyright (c)2005-2010 Daniel Mealha Cabrita

PROGNAME= »Ziproxy »

# source function library

# . /etc/init.d/functions

rc_done= » done »

rc_failed= » failed »

return=$rc_done

PID_FILE=/var/run/ziproxy.pid

ZIPROXY=/usr/bin/ziproxy

ZIPROXY_CONF=/etc/ziproxy/ziproxy.conf

RUN_AS_USER=ziproxy

case « $1 » in

start)

printf « Starting %s:  » « ${PROGNAME} »

${ZIPROXY} -d -u ${RUN_AS_USER} -c ${ZIPROXY_CONF} -p ${PID_FILE}

if [ $? != 0 ]; then

printf « %s » « ${rc_failed} »

else

printf « %s » « ${rc_done} »

fi

echo

;;

stop)

printf « Stopping %s:  » « ${PROGNAME} »

${ZIPROXY} -k -u ${RUN_AS_USER} -c ${ZIPROXY_CONF} -p ${PID_FILE}

if [ $? != 0 ]; then

printf « %s » « ${rc_failed} »

else

printf « %s » « ${rc_done} »

fi

echo

;;

restart|reload)

$0 stop

$0 start

;;

*)

printf « Usage: %s {start|stop|restart}\n » « ${PROGNAME} »

exit 1

esac

On teste que le daemon démarre et s’arrête correctement:

sudo /etc/init.d/ziproxy start

Starting Ziproxy: done

—

ps auxw | grep ziproxy

ziproxy 5429 0.0 0.0 3260 660 ? Ss 14:42 0:00 /usr/bin/ziproxy -d -u ziproxy -c /etc/ziproxy/ziproxy.conf -p /var/run/ziproxy.pid

—

sudo /etc/init.d/ziproxy stop

Stopping Ziproxy: done

Configuration en mode proxy simple

Peu de chose à modifier dans le fichier de configuration /etc/ziproxy/ziproxy.conf:

Port = 8080

Address = 192.168.0.253

# DebugLog = « /var/log/ziproxy/debug.log »

ErrorLog = « /var/log/ziproxy/error.log »

AccessLog = « /var/log/ziproxy/access.log »

## ****** THESE OPTIONS ARE EXPERIMENTAL ******

# ProcessHTML = false

# ProcessCSS = false

# ProcessJS = false

On relance ensuite le serveur pour prendre en compte la configuration:

sudo /etc/init.d/ziproxy restart

Il faut ensuite configurer son navigateur Web pour utiliser ce serveur comme proxy. Par exemple si votre serveur à l’adresse IP 192.168.0.253 et que Ziproxy est configuré sur son port découte par défaut (TCP/8080), il faut configurer le proxy de la manière suivante (exemple sous navigateur Web Chromium):

Test de Ziproxy

Une fois votre navigateur configuré, vous pouvez surfer sur le Web. Les pages s’affichent « normalement ». Nous allons comparer la qualité des images affichées avec et sans Ziproxy et regarder d’un peu plus près le gain en terme de volume de données transmises sur le réseau.

Taille de la page sans Ziproxy: 1.2 Mo (dont 592 Ko d’images)

Taille de la page avec Ziproxy: 0.9 Mo (dont 247 Ko d’images)

On a donc un gain d’environ de 25% en terme de taille. Selon les sites, ce gain varie entre 15 et 35%.

Pour mieux juger la qualité des images recompressés en JPEG voici un zoom à 500%:

Sans Ziproxy

Avec Ziproxy

JPEG 2000…

… ou l’histoire d’un format qui a du mal à prendre…

Pour activer le support de la compression au format JPEG-2000, il faut ajouter l’option suivante dans le fichier de configuration:

ProcessJP2 = false

ProcessToJP2 = true

ForceOutputNoJP2 = false

AnnounceJP2Capability = true

Malheureusement ce format d’image n’est pas pris en compte par les navigateur Web que j’ai testé (dernière version de Chromium et de Firefox…). Un plugin expérimental est disponible sous Firefox pour le support des images JP2 mais pas dans ma configuration (Ubuntu 10.04 + Firefox 3.6.10):

C’est bien dommage car le facteur de compression aurait été plus important…

Configuration en mode proxy secondaire de Squid

Ziproxy ne met pas en cache les données. C’est pour celà qu’il peut être intéressant de le coupler avec un serveur Squid. Voici la configuration cible (avec Squid et Ziproxy hébergés sur la même machine):

Configuration de Ziproxy en éditant le  fichier /etc/ziproxy/ziproxy.conf (attention configuration non complète):

Port = 8080

Address = « 127.0.0.1 »

TransparentProxy = false

ConventionalProxy = true

Puis on ajoute les lignes suivante dans la configuration du serveur Squid pour prendre en charge Ziproxy

cache_peer localhost parent 8080 0 no-query no-digest

never_direct allow all

Il faudra re-configuer vos clients pour  utiliser Squid comme proxy (et non plus Ziproxy). Le port TCP par défaut en écoute du serveur Squid est le 3128.

On peut trouver d’autres exemples de configurations sur cette page.

Catégories
Nagios Open-source Reseau

Nagios 3.2.2 est disponible, les scripts Nicolargo aussi !

C’est la rentrée des classes dans le mini-monde de la supervision: en bon élève Nagios sort une nouvelle version de son coeur (Nagios Core 3.2.2). Pour une liste complète des nouveautés et corrections de bugs, je vous conseille la lecture de cette page.

En parallèle j’ai modifié les scripts d’installation et de mise à jour de Nagios pour qu’il prenne en compte cette nouvelle version.

Si vous avez suivi mon tutoriel d’installation de Nagios (ou que vous avez utilisé le script), il suffit de saisir les commande suivantes pour effectuer une mise à jour de votre serveur:

wget http://svn.nicolargo.com/nagiosautoinstall/trunk/nagiosautoupdate-ubuntu.sh

chmod a+x nagiosautoupdate-ubuntu.sh

sudo ./nagiosautoupdate-ubuntu.sh

Attention: cette méthode de mise à jour ne fonctionnera pas si vous avez installé Nagios à partir des dépôts officiels de votre distribution.

Et hop !

Catégories
Open-source Reseau

De l’utilité de gérer des serials DNS standards

Depuis la migration de mon nom de domaine vers les serveurs Gandi (suite au hack du site), le blog de Nicolargo est injoignable depuis certains FAI (notamment les Freenautes ce qui le coupe de plus d’un tiers du trafic Français)…

Après des échanges ping pong entre le support de Gandi et celui de Free, j’ai décidé de prendre les choses en main, du moins en ce qui concerne l’identification du problème.

Le comportement est le suivant: sur le réseau Free, certains lecteurs voient normalement le blog tandis que d’autre sont redirigé vers l’ancienne adresse du serveur (aujourd’hui un compte iWeb8 suspendu). J’arrive parfaitement à reproduire ce comportement depuis chez moi (et oui je suis chez Free ;)).

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 85644 IN SOA ns1.panelboxmanager.com. logs.logs.privatedns.com. (
2010072800 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
86400 ; minimum (1 day)
)
nicolargo.com. 13644 IN A 72.55.186.68
nicolargo.com. 85644 IN NS ns1.panelboxmanager.com.
nicolargo.com. 85644 IN NS ns2.panelboxmanager.com.
nicolargo.com. 13644 IN MX 0 nicolargo.com.

—

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 10080 IN MX 10 spool.mail.gandi.net.
nicolargo.com. 10080 IN MX 50 fb.mail.gandi.net.
nicolargo.com. 10080 IN A 217.70.184.38
nicolargo.com. 10080 IN SOA a.dns.gandi.net. hostmaster.gandi.net. (
1282917455 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
10800 ; minimum (3 hours)
)
nicolargo.com. 10080 IN NS a.dns.gandi.net.
nicolargo.com. 10080 IN NS b.dns.gandi.net.
nicolargo.com. 10080 IN NS c.dns.gandi.net.

Une fois la résolution de nom se fait normalement (c’est à dire avec les NS pointant chez Gandi: dns.gandi.net), une fois non (les DNS pointent encore sur panelboxmanager.com, les serveurs DNS de iWeb8).

En regardant de plus près la réponse on peut voir les deux lignes suivantes:

Réponse venant de iWeb8: « 2010072800 ; serial »

Réponse venant de Gandi: « 1282917455 ; serial »

Je commence alors à comprendre d’ou vient le problème: quand le domaine était géré par iWeb8, ces derniers utilisait une gestion standard des numéro de série au format ANNEE-MOIS-JOUR-ID (2010072800), ce qui n’est pas le cas de Gandi qui doit générer dynamiquement ce numéro avec un algorithme interne (1282917455). Dans mon grand malheur, le numéro de série Gandi de la zone DNS nicolargo.com est inférieur à celui chez iWeb8. Il est donc normal que les serveurs DNS ne soit pas mis à jour…

Un petit tour du coté d’un site de validation de zone DNS:

Je viens d’envoyer un mail au support Gandi pour qu’il me change le numéro de série SOA à une valeur > à  2010072800…

Sinon il ne me reste plus qu’a attendre l’expiration de la zone DNS, c’est à dire presque… 6 semaines !!! Heureusement que je ne vie pas de ce blog :). Une autre solution serait de gérer moi même mon propre serveur DNS (c’est possible en mode expert sur les VPS Gandi), mais je n’ai pas vraiment le couple temps/envie de m’en occuper.

L’erreur que j’ai faite est de ne pas avoir modifier la zone DNS chez iWeb avant de clôturer mon compte… Cette aventure est quand même une bonne leçon à retenir pour les administrateurs de domaines DNS (par exemple pour ceux qui doivent installer un BIND): respecter les standards de numérotation des serials SOA !

Update (j+9): Comme le signale Pascal dans son commentaire le serial SOA n’est utile que pour la réplication des zones entre le serveur primaire et le/les serveurs secondaires. Ce sont les TTL des RR qui fixent le temps de rafraîchissement des caches DNS (hébergé chez les FAI). Manifestement les serveurs de caches DNS de Free ne tiennent pas compte de ces TTL (fixés à 48h pour le domaine nicolargo.com) ou sont tout simplement bugués…

Update (j+10): Je n’arrive malheureusement pas à avoir une réaction de la part du support de Free, il me dise que la mise à jour des caches se fait de manière automatique (je veux bien les croire sur ce point…) et qu’ils ne peuvent pas intervenir. Bref 10 jours après la migration, certain utilisateur ne peuvent toujours pas accéder au blog. Si quelqu’un connait un administrateur réseau chez Free je suis preneur !!!!

Update (j+11): Tout semble enfin être rentré dans l’ordre. Les DNS de Free sont enfin à jour. Le blog est donc accessible depuis l’ensemble des lecteurs. Si ce n’est pas le cas, c’est plus un problème de cache local de votre navigateur Web (d’un autre coté vous ne pouvez pas lire ce message :)).

Catégories
Open-source Reseau

XPlico, le compagnon idéal de WireShark

C’est en lisant le flux RSS de Korben que je suis tombé sur le projet open-source Xplico. Ce dernier a pour but de présenter de manière lisible les fichiers de capture réseau au format PCap (générés notamment par WireShark et TCPDump).

Actuellement en développement (version 0.5.7 au moment de l’écriture de cet article), Xplico se base sur une architecture ouverte permettant d’ajouter assez simplement des modules de décodage (manipulators) et de visualisation (vizualization) de protocoles.

Nous allons maintenant voir comment installer, configurer et utiliser XPlico sur une système d’exploitation Debian like (Debian / Ubuntu…).

Lire la suite « XPlico, le compagnon idéal de WireShark »
Catégories
Reseau

Configurer un tunnel IPSec Cisco entre deux réseaux locaux

Un petit poste « pense-bête » pour configurer un tunnel IPSec avec « pre-share key » (c’est à dire une clés secrète seulement connue par les deux sites) et cryptage AES 256 bits entre deux LAN connectés à Internet par des routeurs Cisco (compatible avec IPSec…).

Configuration du routeur A

crypto isakmp policy 1
 authentication pre-share
 lifetime 86400

crypto isakmp key AZERTYUIOPQSDFGHJKLMWXCVBNAZERTY address 80.80.80.2

crypto ipsec transform-set MATS esp-aes 256 esp-sha-hmac

crypto map MAMAP 10 ipsec-isakmp
 set peer 80.80.80.2
 set transform-set  MATS
 match address IPSEC-TUN

ip access-list extended IPSEC-TUN
 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

interface FastEthernet 0/1
 crypto map MAMAP

Configuration du routeur B

crypto isakmp policy 1
 authentication pre-share
 lifetime 86400

crypto isakmp key AZERTYUIOPQSDFGHJKLMWXCVBNAZERTY address 80.80.80.1

crypto ipsec transform-set MATS esp-aes 256 esp-sha-hmac

crypto map MAMAP 10 ipsec-isakmp
 set peer 80.80.80.1
 set transform-set  MATS
 match address IPSEC-TUN

ip access-list extended IPSEC-TUN
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

interface FastEthernet 0/1
 crypto map MAMAP
Catégories
Open-source Reseau

Tester une liaison TCP/IP avec nttcp

NTTcp est un petit utilitaire bien pratique, dans la lignée des IPerf, pour tester une liaison TCP/IP (ou UDP) en ligne de commande sous Linux. A ajouter à votre liste d’outils pour l’administrateur réseau…

Installation de NTTcp

Il faut installer le logiciel sur les deux machines (ou plus) entre lesquelles vous voulez tester votre réseau TCP/IP.

Sous Ubuntu:

[shell]sudo aptitude install nttcp[/shell]

Utilisation de NTTcp

Sur la machine A ayant comme adresse IP 192.168.0.100 (d’un coté du réseau):

[shell]nttcp -i -v[/shell]

Sur la machine B (de l’autre coté du réseau à tester):

[shell]nttcp -t -T 192.168.0.100[/shell]

Par défaut, NTtcp va transférer 2048 « buffers » de 4 Kilo octets (4KB), soit un total de 8 Mo de B vers A.

Le résultat devrait ressembler à:

     Bytes  Real s   CPU s Real-MBit/s  CPU-MBit/s   Calls  Real-C/s   CPU-C/s
l  8388608    0.71    0.02     93.8840   3355.2754    2048   2865.11  102394.9
1  8388608    0.72    0.06     92.7279   1198.3084    5209   7197.55   93012.9

Les options disponibles

Pour inverser et effectuer un test de débit de A vers B, il faut utiliser l’option -r au lieu de l’option -t.

On peut notamment noter l’option -u pour forcer l’utilisation du protocole UDP en lieu et place de TCP.

Un petit coup de man:

[shell]

Usage: nttcp [local options] host [remote options]
local/remote options are:
-t transmit data (default for local side)
-r receive data
-l# length of bufs written to network (default 4k)
-m use IP/multicasting for transmit (enforces -t -u)
-n# number of source bufs written to network (default 2048)
-u use UDP instead of TCP
-g#us gap in micro seconds between UDP packets (default 0s)
-d set SO_DEBUG in sockopt
-D don’t buffer TCP writes (sets TCP_NODELAY socket option)
-w# set the send buffer space to #kilobytes, which is
dependent on the system – default is 16k
-T print title line (default no)
-f give own format of what and how to print
-c compares each received buffer with expected value
-s force stream pattern for UDP transmission
-S give another initialisation for pattern generator
-p# specify another service port
-i behave as if started via inetd
-R# calculate the getpid()/s rate from # getpid() calls
-v more verbose output
-V print version number and exit
-? print this help
-N remote number (internal use only)
default format is: %9b%8.2rt%8.2ct%12.4rbr%12.4cbr%8c%10.2rcr%10.1ccr

[/shell]

Catégories
Open-source Reseau

SpiderOAK en ligne de commande

Vous savez (ou pas) tout le bien que je pense du service de stockage en ligne SpiderOAK. Après avoir détailler l’installer et la configuration du logiciel client SpiderOAK sur un PC Ubuntu Desktop disposant d’une interface graphique, nous allons voir comment utiliser ce service sur un serveur seulement accessible en ligne de commande (SSH).

Principe

En effet, le client SpiderOAK peut être lancé en ligne de commande (vous pouvez voir la liste des options disponibles en lancant /usr/bin/SpiderOak –help). Malheureusement, il n’est, à l’heure actuelle, pas possible de configurer le client par cette méthode. Nous allons donc:

  • installer le client SpiderOAK sur le serveur
  • en utilisant les fonctions x-forwarding de SSH, lancer le client à distance (l’interface s’affichera sur  votre machine locale) puis faire la configuration (c’est à dire choisir les répertoires à sauvegarder)
  • automatiser le lancement du client en ligne de commande (via crontab)

Aller zou à vos claviers…

Installation du client SpiderOak sur le serveur

On commence par télécharger la dernière version du client (attention de choisir une version compatible avec votre serveur: AMD64 / i386…) sur sa machien locale (on doit obtenir un fichier nommé spideroak_9658_i386.deb ou quelque chose comme ça…).

On copie ensuite ce fichier vers le serveur:

[shell]scp spideroak_9658_i386.deb monlogin@monserveur.com[/shell]

On se connecte en SSH sur le serveur:

[shell]ssh login@monbeauserveur.com[/shell]

Puis on lance l’installation:

[shell]sudo dpkg -i spideroak_9658_i386.deb[/shell]

Avant de fermer la session SSH, on installe xauth qui va nous permettre de lancer SSH en mode x-forwarding (exemple d’installation sur une distribution Ubuntu Serveur) ainsi que quelques librairies dépendantes:

[shell]

sudo aptitude install xauth dbus libice6 libsm6 libxrender1

exit

[/shell]

Configuration du client à distance

On lance une nouvelle session SSH en activant le x-forwarding (option -X):

[shell]ssh -X login@monbeauserveur.com[/shell]

Puis on lance le client SpiderOak:

[shell]/usr/bin/SpiderOak[/shell]

Il ne reste plus qu’a choisir dans l’interface graphique les répertoires à sauvegarder (voir un screencast de démonstration ici).

Une fois le client configuré, vous pouvez fermer l’application.

Lancement du client sur le serveur

Pour lancer le client sans interface graphique, il suffit de saisir la commande suivante (dans votre session SSH):

[shell]/usr/bin/SpiderOak –headless &[/shell]

Enfin pour automatiser le lancement du client au démarrage du serveur, il suffit d’ajouter une ligne à votre crontab:

[shell]

# crontab -e

@reboot /usr/bin/SpiderOak –headless &

[/shell]

Si vous avez besoin de reconfigurer votre client (pour ajouter ou supprimer un répertoire à sauvegarder), il faut:

  • se connecter au serveur en SSH avec l’option -X
  • tuer le process SpiderOak existant
  • lancer la commande: /usr/bin/SpiderOak
  • Configurer puis quitter l’interface
  • lancer la commande: /usr/bin/SpiderOak –headless &

Voili, plus d’excuses pour perde ses données 🙂

Source: Le blog de Marc Seeger

Catégories
Open-source Reseau

Tester le débit de votre liaison réseau en fonction de la taille des paquets

Vous le savez (ou pas) mais la performance de vos applications réseau ne dépends pas seulement du débit et du délais de transit de votre liaison. Un des paramètre à prendre en compte est la taille des paquets générés par vos applications. C’est sur ce postulat que le logiciel Netpipe-TCP a été developpé.

NPtcp (disponible dans le package Netpipe-TCP sous Ubuntu) est un petit utilitaire bien pratique, en ligne de commande, permettant de tester le débit maximal d’une liaison en fonction de la taille des paquets.

Installation de NPtcp

Il faut installer le logiciel sur les deux machines (ou plus) entre lesquelles vous voulez tester votre réseau TCP/IP.

Sous Ubuntu:

sudo aptitude install netpipe-tcp

Utilisation de NPtcp en mode TCP

Sur la machine A ayant comme adresse IP 192.168.0.100 (d’un coté du réseau):

NPtcp

Sur la machine B (de l’autre coté du réseau à tester):

NPtcp -h 192.168.0.100

Il est important de noter que NPTcp va faire un test bi-directionnel (c’est à dire que les flux seront envoyé simultanément de A vers B et de B vers A). Pour tester seulement de B vers A, on peut utiliser l’option -s (à ajouter sur les deux lignes de commande).

Le résultat devrait ressembler à:

Send and receive buffers are 16384 and 87380 bytes
(A bug in Linux doubles the requested buffer sizes)
Now starting the main loop
 0:       1 bytes    648 times -->      0.05 Mbps in     142.98 usec
 1:       2 bytes    699 times -->      0.11 Mbps in     144.26 usec
 2:       3 bytes    693 times -->      0.16 Mbps in     145.62 usec
 3:       4 bytes    457 times -->      0.21 Mbps in     145.54 usec
 4:       6 bytes    515 times -->      0.31 Mbps in     145.94 usec
 5:       8 bytes    342 times -->      0.42 Mbps in     144.11 usec
 6:      12 bytes    433 times -->      0.63 Mbps in     146.39 usec
 7:      13 bytes    284 times -->      0.67 Mbps in     147.55 usec
 8:      16 bytes    312 times -->      0.83 Mbps in     147.73 usec
 9:      19 bytes    380 times -->      0.98 Mbps in     148.04 usec
 10:      21 bytes    426 times -->      1.07 Mbps in     150.25 usec
...

Comment lire les résultats ?
On obtient donc un débit de 0.63 Mbps pour des tailles de paquets TCP de 12 octets, 1 Mbps pour 21 octets…

Et si l’on veut générer un beau graphe

Et oui, les chefs, les tableaux et les résultats en mode texte ils n’aiment pas ça… Donc pour assurer votre prochaine augmentation, nous allons, avec l’aide de gplot, compulser les chiffres générés par NPTcp dans un « beau » graphe…

On commence par ajouter l’option « -o fichier »:

Sur la machine B (de l’autre coté du réseau à tester):

NPtcp -h 192.168.0.100 -o nptcp.out

Puis on trace le graphe:

echo « reset; set terminal png; \

set logscale x;

set xlabel ‘Taille des paquets (octets)’; \

set ylabel ‘Debits (Mbps)’; \

plot ‘nptcp.out’ using 1:2 with linespoints; » | gnuplot > nptcp.png

Et on a le résultat suivant (sur une liaison LAN):

Quelques options en bonus…

Pour simuler un flux unidirectionnel de B vers A (streaming):

A# NPtcp -s

B# NPtcp -h 192.168.0.100 -s -o nptcp.out

Pour limiter le test a une taille maximale de paquet de 256 Ko:

NPtcp -h 192.168.0.100 -u 256000 -o nptcp.out

Pour fixer une taille minimale à 16 Ko:

NPtcp -h 192.168.0.100 -u 256000 -l 16000 -o nptcp.out

Conclusion

Un bon outil de plus à ajouter a son couteau suisse des applications open-source pour l’administration et le test de son réseau !