Génération de certifications OpenVPN par lots avec pkitool

Ce blog n’est pas particulièrement actif ces derniers temps comme vous pouvez le remarquer. Surement une petite baisse de motivation de ma part mais également les vacances. Aujourd’hui ce sera donc un petit article simple mais efficace.

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

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

#! /bin/bash
# Make a certificate/private key pair using a locally generated
# root certificate.
export EASY_RSA= »`pwd` »
export OPENSSL= »openssl »
export PKCS11TOOL= »pkcs11-tool »
export GREP= »grep »
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR= »$EASY_RSA/keys »
export PKCS11_PIN= »dummy »
export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY= »FR »
export KEY_PROVINCE= »FR »
export KEY_CITY= »Paris »
export KEY_ORG= »Antoine-Corp »
export KEY_EMAIL= »me@myhost.mydomain »
export KEY_CNAME=$1
export EASY_RSA= »${EASY_RSA:-.} »
« $EASY_RSA/pkitool » $*

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

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

Architecture réseau d’une LAN Party : Conception

Ce billet fait suite au précédent qui avait eu pour objectif de définir le contexte d’un réseau d’une LAN et de présenter le projet. Aujourd’hui, nous allons définir l’architecture IP et L2 de notre LAN.

Avant de commencer, je souhaite faire un petit point d’avancement. La préparation de l’Utt Arena a commencé quelque peu en retard au niveau du réseau pour diverses raisons. Les choses avancent donc très vite et je vais essayer de vous faire partager notre avancement sur ce blog du mieux possible. J’approfondirais plus ou moins les sujets en fonction du temps que j’ai à ma disposition.

Je pense que l’architecture d’un réseau se doit d’être la plus simple possible et la plus logique possible. Si un réseau est simplement compréhensible par un humain, il sera plus facile à gérer et les sources d’erreur seront réduites. La conception de l’architecture est une phase exceptionnellement critique sur laquelle repose tout le reste.

L’objectif de notre réseau est le contrôle des flux et la l’optimisation de la latence. Ces deux objectifs sont quelque peu contradictoires car le contrôle des flux implique l’ajout d’intermédiaires de filtrage et de routage. Nous avons essayé de concilier au mieux ces deux objectifs.

Nous avons créé un VLAN par switch de table ce qui correspond à 20 joueurs pour les tournois CS et CSS. Ces deux tournois sont, de loin, les plus problématiques en terme d’utilisation réseau. Ceci nous fait donc 8 VLAN pour CS et 4 VLAN pour CSS. Pour les tournois TrackMania et Warcraft III, nous avons choisi de faire un VLAN par tournoi. Les joueurs Warcraft III jouent entre eux sans passer par un serveur, il est donc plus simple de les placer dans un VLAN dédié.

Tous les VLAN contenant les joueurs seront routés par un ASA. Nous avons ensuite réparti les VLAN équitablement parmi les ASA.

Ensuite, nous devons interconnecter les ASA entre eux. Nous avons choisi le protocole de routage OSPF car il s’agit d’un protocole simple et efficace. La logique traditionnelle voudrait que nous insérions un routeur central afin de router les flux des 4 ASA. Etant donné que notre objectif est la latence, nous avons choisi de ne pas mettre ce routeur. Les ASA seront donc tous interconnectés par le même réseau IP. OSPF est parfaitement capable de gérer cette configuration en passant par l’élection d’un DR (Designated Router).

Nous avons ensuite ajouté deux routeurs standards afin de router les flux des serveurs et des administrateurs. Ces routeurs participeront également à l’OSPF avec les ASA.

Et pour finir la tache la plus importante, le nommage des équipements. Inutile mais tellement indispensable et amusant. Nous avons choisi des noms de volcans pour les ASA et des noms de montagne pour les routeurs. Les ASA s’appelleront ainsi Etna, Fuji, Kilauea et Pinatubo et les routeurs Everest et K2.

Cliquez sur l’image pour l’agrandir.

Au final, nous obtenons un schéma relativement effrayant. Ce dernier nous a permis de nous rendre compte de la taille du réseau que nous avons projeté de mettre en place. La difficulté est, honnêtement, un facteur très motivant. Cette réflexion a été faite avec toute l’équipe réseau et avec le retour de personnes extérieures ce qui a permis de dynamiser la réflexion.

Dans les prochains épisodes : la spécificité de la configuration des ASA et un rebondissement inattendu ! Quel suspens !

Installation d’OpenVPN sur OpenSolaris

Cela fait un bon bout de temps que je n’ai pas eu l’occasion de vous parler d’OpenSolaris. Le dernier article remonte même à mi-Novembre ! Je n’ai pas abandonné ni laissé tomber OpenSolaris, loin de là. La machine virtuelle hébergeant ce blog a été migrée sur OpenSolaris comme j’avais eu l’occasion de l’expliquer dans un article précédent. Je vais donc profiter de ces quelques jours de vacances rallongées (hélas) pour vous parler de l’installation d’OpenVPN sur OpenSolaris.

Pour rappel, OpenVPN est une application qui permet de créer des tunnels VPN chiffrés afin d’y faire passser du trafic IP. Cette application est relativement simple à utiliser une fois qu’on a réussi à comprendre rapidement son fonctionnement. Je vous en avais déjà parlé à travers l’article sur Viscosity, client VPN pour MacOS. Si vous êtes intéressés par un tutoriel d’installation sous Linux, je vous renverrais vers l’excellent tutoriel écrit par Smurf.

Pré-requis

Afin de pouvoir installer OpenVPN sur OpenSolaris, il va vous falloir une installation fonctionnelle d’OpenSolaris. Logique, non ? Nous allons ensuite travailler avec les packages fournis par Blastwave. Il s’agit d’un dépot de paquets spécifiques de manière similaire au dépots Sun. L’avantage de Blastwave est que les paquets sont plus nombreux et plus récents. Le nom des paquets Blastwave commencent par CSW au lieu de SUNW pour les paquets Sun. Afin de pouvoir installer facilement des paquets Blastwave, il est nécessaire de récupérer et installer l’utilitaire d’installation pkgutil (sorte d’équivalent à apt-get).

# wget ftp://ftp.belnet.be/packages/blastwave.org/pkgutil_1.6.1_i386.pkg

# pkgadd -d pkgutil_1.6.1_i386.pkg

Une fois cette utilitaire installé, nous allons pouvoir installer le reste beaucoup plus simplement.

Installation

Tout d’abord, nous allons devoir récupérer et installer les modules tun et tap nécessaires pour le fonctionnement d’OpenVPN. Une fois que ces modules seront installés, nous allons pouvoir nous occuper d’OpenVPN. De manière similaire à apt-get, la récupération des binaires et leur installation est automatique.

# /opt/csw/bin/pkgutil -i tun tap
# /opt/csw/bin/pkgutil -i openvpn

L’installation de tous ces paquets se fait toute seule. Il sera juste peut être nécessaire de confirmer l’installation en tapant un simple « y ».

Génération des certificats

Une fois l’installation initiale des paquets terminée, nous allons nous attaquer à la génération des certificats. Nous allons tout d’abord créer le certificat racine de notre serveur OpenVPN. Le certificat racine est le certificat d’origine qui servira à signer tous les certifications délégués aux utilisateurs de notre concentrateur VPN.

# cd /etc/csw/openvpn/easy-rsa
# source vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /etc/csw/openvpn/easy-rsa/keys
# ./clean-all
# ./build-ca
Generating a 1024 bit RSA private key
.++++++
………..++++++
writing new private key to ‘ca.key’

Un certain nombre de questions vous seront ensuite posées. Les réponses à ces questions permettront de pouvoir identifier plus clairement votre certificat racine. Rassurez-vous, il n’y a donc pas de mauvaise réponse. Une fois que vous aurez fini, vous remarquerez que deux nouveaux fichiers ont été créés : ca.crt et ca.key. Le fichier ca.key est à garder précieusement car c’est ce dernier qui permet de signer et de créer de nouveaux certificats donnant accès à votre concentrateur VPN. Nous allons ensuite créer le jeu de clés du serveur OpenVPN.

# ./build-key-server server
Generating a 1024 bit RSA private key
………………………………………………++++++
………………..++++++
writing new private key to ‘server.key’

Une fois le certificat du serveur créé, vous retrouverez les fichiers server.key et server.crt. Nous allons ensuite pouvoir créer les certificats de nos utilisateurs. Des informations vous seront également demandées sur l’utilisateur pour la création de certificat. Ces informations permettent d’identifier vos utilisateurs, vous avez donc tout intérêt à les remplir précisément.

# ./build-key antoine
# ./build-key jeanmarc

Afin d’achever la génération des certificats, nous allons devoir créer le paramètre de Diffie-Hellman. La génération peut prendre du temps surtout sur un processeur peu occupé.

/etc/csw/openvpn/easy-rsa# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time

Configuration d’OpenVPN

Tout d’abord, nous allons devoir rendre accessible au service les différents certificats dont il va avoir besoin.

# cd /etc/csw/openvpn
# /etc/csw/openvpn# cp openvpn.conf.CSW openvpn.conf
# /etc/csw/openvpn# ln -s easy-rsa/keys/dh1024.pem
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.crt
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.key
# /etc/csw/openvpn# ln -s easy-rsa/keys/ca.crt

Il est nécessaire ensuite de renseigner les différentes informations dans le fichier de configuration d’OpenVPN. Je ne parlerais pas de ce fichier en détail ici car d’autres sites le font déjà et bien mieux que moi. Les lignes importantes sont les suivantes. L’utilisation de TCP pour un VPN est sous-optimal mais permet de contourner une bonne partie des firewalls associé avec le port 443 (HTTPS).

port 443
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 172.19.0.0 255.255.255.0

Ensuite, vous allez pouvoir tester votre paramétrage en exécutant le service OpenVPN.

# ifconfig tun0 unplumb
# /opt/csw/sbin/openvpn /etc/csw/openvpn/openvpn.conf

L’affichage des logs sera fera directement sur votre écran ce qui vous permettra de diagnostiquer d’éventuelles erreurs de configurations ou de connexion. Et ensuite, pour lancer définitivement le démon :

# ifconfig tun0 unplumb && /etc/init.d/openvpn start

Au final, ce petit tutoriel vous permettra de créer un tunnel OpenVPN afin de pouvoir communiquer avec votre serveur de manière sécurisée. Je ferais un autre billet expliquant les manipulations supplémentaires pour passer toute sa connexion Internet dans ce même VPN. Ce tutoriel est largement inspiré d’un autre tutoriel en anglais.

Un client OpenVPN pour Mac OS : Viscosity

Je suis heureux possesseur d’un MacBook depuis Octobre dernier. Avant cet achat, j’avais toujours été un utilisateur de PC en tous genres sous Windows puis sous Linux. Le passage à Mac fait un certain changement. Je ne parlerais pas d’un gros changement car en tant qu’utilisateur de Linux, on retrouve assez vite des repères.

Qui dit PC portable, dit mobilité. Qui dit mobilité, dit hotspot wifi non sécurisés. Un portable est donc une machine particulièrement sensible en terme de confidentialité des données et des échanges avec Internet. Utiliser Internet sur un hotspot public est particulièrement peu sécurisé surtout dans les grands lieux publiques tels que les gares SNCF. Il est possible de récupérer tous types de données transmises en clair très simplement. De plus, lorsqu’on se retrouve sur un réseau convenablement protégé de nombreux ports sont bloqués et il peut s’appliquer un filtrage web.

L’utilisation d’OpenVPN s’impose donc. Je sais qu’il existe de nombreuses alternatives payantes telles que Cisco VPN ou autres mais pour une utilisation personnelle, c’est plutôt superflu. Lorsque mon PC portable était sous Ubuntu, l’utilisation d’OpenVPN était tout à fait simple. Il suffisait de refaire le fichier de configuration en se calquant sur le serveur et le tour était joué. Au passage, pour installer OpenVPN, je vous conseille de consulter le tutoriel de Smurf disponible sur le site de Gayux.

Pour les utilisateurs de MacOS, je vous recommande donc chaleureusement l’application Viscosity.

L’installation se fait de manière tout à fait simple. Il suffit d’ouvrir le .dmg et de cliquer sur l’installeur. Il vous demandera plusieurs fois votre mot de passe root afin de pouvoir installer les différents modules nécessaires à son bon fonctionnement.

La configuration se fait de manière très simple. L’intitulé des champs à renseigner ressemble beaucoup aux différentes directives du fichier de configuration d’OpenVPN. Vous avez également la possibilité de visionner le log de la connexion à votre serveur VPN afin de pouvoir détecter de potentielles erreurs.

gui1

Cette application vous permet également de visionner quelques statistiques d’utilisation de votre liaison VPN. C’est pas super utile mais non moins joli.

detailswin

Une petite icône présente sur la barre du haut de votre écran vous permet à tout moment d’avoir un aperçu de l’état de votre connexion et de passer d’un VPN à un autre.

screenshot1_small

Au final, Viscosity est une application très efficace qui fait ce qu’on lui demande de faire. En plus, elle est plutôt jolie. Vous pouvez l’essayer gratuitement pendant 30 jours et puis ensuite vous pourrez l’acheter pour la modique somme de 9 USD.