Nous allons voir ici la création d’un serveur OpenVpn en mode ponté, c’est-à-dire qu’à chaque client du VPN sera attribué une adresse du réseau local côté serveur. C’est le routeur en charge du DHCP côté serveur qui distribuera les adresses aux clients VPN. La carte réseau physique (eth0) et la carte réseau virtuelle (tap0) seront donc bridgées ensemble sous l’interface br0. Nous allons aussi faire en sorte de gérer la révocation des certificats. La base est une installation sans graphique de Debian Wheezy.

Ce tuto est en très grande partie de celui de Mattotop sur le forum debian-fr.org. J’ai fait quelques petites modifications, mais je ne serai certainement pas arrivé à grand-chose sans lui.

Comme le paquet openssl est requis, et que tout le monde parle de Heartbleed en ce moment, on en profite pour vérifier que’on a bien la ligne deb http://security.debian.org/ wheezy/updates main contrib non-free dans notre sources.list :)

Commencer par installer les paquets nécessaires : aptitude install bridge-utils openvpn openssl rcconf

On se positionne dans le répertoire de configuration d’OpenVPN : cd /etc/openvpn

On y copie le dossier easy-rsa contenant tous les scripts de gestion du serveur et des clients :

cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/ ./easy-rsa

(note : sous Jessie, il faut installer le paquet easy-rsa, et la conf se trouve directement à /usr/share/easy-rsa)

On rentre dans le dossier easy-rsa :

cd easy-rsa

Puis on édite le fichier vars, qui contient les valeurs communes pour la génération des certificats. Ce sont principalement les informations des dernières lignes à adapter selon nos besoins :

nano ./vars

Puis on “source” ce fichier, pour exporter toutes les valeurs dans nos variables d’environnement. Il faudra faire cette opération chaque fois que nous voudrons agir sur les certificats, par exemple pour générer de nouveaux certificats ou en révoquer.

. ./vars

Le script nous avertir que si on lance la commande ./clean-all, il va (ré)initialiser le répertoire keys, qui contiendra toutes nos clés. Ça tombe bien, c’est une install neuve, nous souhaitons le faire :

./clean-all

Nous préparaons ensuite les clés et paramètres Diffie-Hellman :

./build-dh
./build-ca
./build-key-server monServeurVpn

Sur la phase de création de la clé du serveur, tout comme pour la phase de création des certificats des clients, il n’est pas obligatoire de mettre un mot de passe. Il faut par contre que chaque CommonName soit unique, et il faut valider les 2 demandes de signature à la fin, en tapant “y”.

Nous allons générer puis révoquer un kit quelconque, ce qui permettra d’initialiser le fichier crl.pem. Ce fichier est indispensable pour que le serveur vérifie la liste des certificats révoqués. Sans ce dernier, un certificat révoqué permettra quand même de se connecter sans souci.

./build-key dummy
./revoke-full dummy

Nous avons maintenant le fichier ./keys/crl.pem qui est initialisé. Note : si nous souhaitons voir le contenu de ce fichier, nous puvons lancer la commande suivante :

openssl crl -text -noout -in keys/crl.pem

Nous créons maintenant un kit pour notre premier client, que l’on conservera :

./build-key client1

Nous passons ensuite à la configuration du serveur. le fichier est à mettre dans le répertoire /etc/openvpn pour être lancé par le service openvpn.

nano /etc/openvpn/monServeurVpn.conf

On y colle ceci :

port 1194
proto udp
dev tap0
ca		/etc/openvpn/easy-rsa/keys/ca.crt
cert	/etc/openvpn/easy-rsa/keys/monServeurVpn.crt
key		/etc/openvpn/easy-rsa/keys/monServeurVpn.key  # This file should be kept secret
dh		/etc/openvpn/easy-rsa/keys/dh1024.pem
server-bridge
keepalive 10 120
comp-lzo
persist-key
persist-tun
status 	/etc/openvpn/openvpn-status.log
#log-append	/etc/openvpn/openvpn.log
verb 3
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem

(ce fichier est épuré au maximum ; vous pouvez récupérer ma version commentée et vous pouvez bien sûr lire les commentaires de l’exemple fourni par Debian ici : /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz )

Le fait que la ligne log-append soit commentée est volontaire : ainsi, nous avons directement la sortie affichée sur le terminal. A ce stade, nous pouvons normalement lancer le serveur.

cd /etc/openvpn
openvpn ./monServeurVpn.conf

doit démarrer OpenVpn et finir sur le message “Initialization Sequence Completed”. Il n’est pas fonctionnel pour autant, car nous n’avons pas configuré le réseau et le pont. Coupons le serveur qu’on vient de lancer avec Ctrl-C.

Il faut déjà désactiver le lancement du service openvpn au démarrage de la machine, car le réseau devra être complètement initialisé auparavant, et le lancement se fera via les scripts d’interface. Passer par la commande

rcconf

et décocher openvpn.

On édite ensuite le fichier /etc/network/interfaces, dans lequel on définit le bridge

cp /etc/network/interfaces /etc/network/interfaces.bak
nano /etc/network/interfaces

qui devra contenir ceci :

auto lo
	iface lo inet loopback

auto br0
	iface br0 inet manual
	bridge-ports eth0
	post-up /etc/openvpn/scripts/ovup && service openvpn start
	pre-down service openvpn stop
	post-down /etc/openvpn/scripts/ovdown

On choisit l’option “manual” car lorsque l’interface se lance, on ne va pas la configurer tout de suite. Ce sera fait lors des scripts dans le post-up.

Le but des scripts mentionnés ci-dessus est de déclencher la configuration de tap0 et le lancement du serveur lors de la mise en route de l’interface br0. Créons maintenant les scripts en question :

mkdir /etc/openvpn/scripts
cd /etc/openvpn/scripts
nano ovup

qui contiendra :

#!/bin/sh
openvpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig eth0 promisc up
ifconfig tap0 promisc up
ifconfig br0 hw ether 1c:6f:65:ff:ff:ff  ## si on veut forcer le pont à avoir une adresse mac précise. Normalement elle prend celle de l'interface physique, mais il m'est arrivé qu'elle prenne celle de l'interface tap0, ce qui perturbe mon dhcp basé sur des baux fixes
ifconfig br0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255

Ce script crée le device tap0, l’ajoute au pont br0 (qui contient déjà eth0), passe eth0 et tap0 en mode Promisc, nécessaire pour que le bridge fonctionne, et configure l’IP de br0. Encore une fois, si on souhaite être en dhcp avec bail fixe, on peut remplace la dernière ligne par dhclient -v br0

nano ovdown

qui contiendra

#!/bin/sh
openvpn --rmtun --dev tap0

On rend ces scripts executables :

chmod +x /etc/openvpn/scripts/ov*

Et normalement, un

service networking restart

devrait tout faire : démarrer le bridge, le configurer, et lancer le vpn. Si la commande se finit par “done.”, c’est que toutes les étapes se sont bien déroulées, et le serveur est prêt à l’emploi :)

Voici des exemples de fichier de conf client fonctionnels, après avoir adapté l’IP du serveur et les chemins du kit de connexion, pour Linux et pour Windows

Lorsque l’on a plusieurs environnements de bureau installés, par exemple KDE, Gnome 3 et Mate, et que l’on utilise LightDM pour gérer la connexion graphique, la connexion se fera automatiquement sur le DE par défaut. Je suppose, sans être sûr, que c’est le dernier installé. On peut modifier ce choix à la volée, avec le menu déroulant prévu pour, mais ceci est à faire à chaque fois, et peut donc être pénible.

pour définir un nouvel environnement par défaut, à l’échelle du système, il suffit d’utiliser les alternatives. C’est donc la commande :

sudo update-alternatives --config x-session-manager

qui permet de voir et choisir à quel DE correspondra ce choix par défaut !

La comande md5sum, disponible en standard sous Linux (paquet coreutils sous Debian), permet de faire le md5 d’un fichier. Si on souhaite faire directement le md5 d’une chaine de caractères, il faut pour ceci utiliser la syntaxe suivante :

echo -n ma chaine de caracteres meme avec des espaces | md5sum

Il est indispensable de passer l’option -n, qui permet de supprimer le retour chariot (mis automatiquemeent par echo) de fin de chaine, qui modifie radicalement le md5.

Grâce au paquet live-build, on peut aisément construire une image personnalisée d’un système live Debian Wheezy. Ceci a été réalisé sous Wheezy en 64 bits, et je souhaitais obtenir une image i386 (pour la compatibilité avec le maximum d’ordinateurs à des fins de dépannage).

Première étape : installer le paquet :

sudo aptitude install live-build

créer un dossier dedié à la construction de l’image et aller dedans :

mkdir debian_live && cd debian_live

créer un dossier auto pour la conf, et y coller les exemples :

mkdir auto && cp /usr/share/doc/live-build/examples/auto/* ./auto/

Préparer la configuration en éditant le fichier auto/config pour qu’il contienne ceci

#!/bin/sh

lb config noauto \
    --architectures 'i386' \
    --archive-areas 'main contrib non-free' \
    --bootappend-live 'boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr' \
    --binary-images 'iso-hybrid' \
    --distribution 'wheezy' \
    --linux-flavours '486 686-pae' \
    --source 'false' \
    --apt 'aptitude' \
    --apt-secure 'false' \
    "${@}"

le --apt-secure 'false' permet d’installer les paquets non-signés pour installer mate.

Puis on initie la configuration :

lb config

Les infos sont récuperées du fichier que l’on vient d’éditer.

Il faut ensuite ajouter les dépôts additionnels ; dans mon exemple celui de Mate, mais cela peut être n’importe quel dépôt. pour cela, créer le fichier

nano ./config/archives/mate.list.chroot

et copier dedans l’adresse du dépôt

deb http://packages.mate-desktop.org/repo/debian/ wheezy main

Ce(s) fichier(s) doit être de la forme xxxx.list.chroot pour être pris en compte automatiquement lors de la construction de l’image (à l’étape du chroot). Il est aussi possible de nommer un fichier xxx.list.binary si l’on souhaite que le dépôt se retrouve dans le sources.list du système live.

Nous spécifions ensuite la liste des paquets que nous souhaitons voir installés dans le système, grâce au fichier :

nano ./config/package-lists/packages.list.chroot

dans lequel nous collons la liste de tous les paquets souhaités. Par exemple :

vlc openoffice.org  openoffice.org-l10n-fr openjdk-7-jre mdadm  rdesktop conky nmap rcconf network-manager-gnome firmware-linux firmware-atheros firmware-b43-installer firmware-bnx2 firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-ipw2x00 firmware-ivtv firmware-iwlwifi firmware-libertas firmware-myricom firmware-netxen firmware-qlogic firmware-ralink firmware-realtek gparted hfsprogs ntfs-3g hfsplus hfsutils dosfstools hplip system-config-printer xsane simple-scan lightdm mate-desktop-environment bash-completion chntpw caja-open-terminal clamav dcfldd bootlogd less mesa-utils numlockx ethtool grub2 mesa-utils ssh gdisk testdisk python-tk iftop nethogs pm-utils dmraid unrar

De la même manière, le format doit respecter la syntaxe xxx.list.chroot pour être pris en compte lors de la construction de l’image.

Puis on peut lancer la construction à proprement parler, en root :

sudo lb build

Qui amène à la création d’un fichier binary.hybrid.iso dans le dossier courant, prêt à être gravé sur cd ou dumpé sur clé usb avec la commande

dd if=./binary.hybrid.iso of=/dev/sdX

Pour plus d’infos, ne pas oublier de consulter les mans :

man live-build
man lb config

Il faut utiliser le paramètre X (x majuscule) à la commande chmod pour indiquer que le flag éxecutable ne doit être mis que sur les dossiers (ou les fichiers qui le possèdent déjà) :

chmod -R u=rwX,go=rX /my/path/*

Suite à une tentative d’upgrader le firmware DD-WRT de mon WRT54GL, la procédure ne s’est jamais terminée, et au reboot suivant, le routeur était briqué : impossibilité de s’y connecter, d’abtenir une adresse ip ou de l’administrer. Le voyant power clignotait rapidement, toutes les autres leds étaient éteintes.

J’ai donc trouvé, suivi et validé cette procédure (http://mediatux.com/openwrt54g.php) que je répète ici :

• télécharger le firmware OpenWRT ici
• ouvrir le routeur. Il faut d’abord retirer les antennes wifi. J’y suis personnellement arrivé en forçant très fort sur les pieds avants du routeur (partie bleue), vers l’avant.
• relier une antenne wifi à la 16e patte du chip sous la puce broadcom avec un fil de cuivre (dans mon cas, un cable d’enceinte a parfaitement fait l’affaire)
• préparer un pc sous linux avec une carte réseau attribuée en ip fixe à l’adresse 192.168.1.3. Relier cette carte au routeur par ethernet.
• se placer dans le dossier contenant le firmware sus-mentionné
• lancer la commande tftp 192.168.1.1 puis > binary > trace >rexmt 1 > timeout 90

Mettre le routeur sous tension. Lorsque seule la diode power est allumée et clignote, lancer sur le pc linux la commande suivante : > put openwrt-wrt54g-squashfs.bin

L’envoi du nouveau firmware est en cours et défile à l’écran. Une fois l’opération terminée (quelques secondes), attendre que le routeur redémarre (SANS LE REBOOTER MANUELLEMENT). une fois opérationnel, le voyant power sera fixe, et OpenWrt bien installé sur le routeur !

Pour dépasser la limite d’une actualisation par jour incluse dans l’interface web, il suffit d’aller dans Administration –> Commands puis taper :

inadyn --dyndns_system default@no-ip.com --username bidule@hotmail.fr --password monSuperPass --update_period_sec 600 --alias machintruc.no-ip.org

et valider en cliquant sur Startup : la commande sera lancée au démarrage, et inadyn actualisera en boucle.

Créer (ou éditer) un fichier .inputrc dans le dossier personnel de l’utilisateur (à côté du .bashrc , donc :) ) , et y placer les 2 lignes suivantes :

"\e[1;5A": history-search-backward
"\e[1;5B": history-search-forward

Ainsi, on peut commencer à taper une commande, et un ctrl+↑ nous fait remonter uniquement dans les commandes qui commencent par ce qui a déjà été tapé !

Dans cet article, ma clé est /dev/sdz . ADAPTEZ A VOTRE CONFIGURATION Cet article est adapté à du i386. Il devrait pouvoir s’adapter facilement à du amd64 avec 2-3 modifs.

Prendre une clé, de minimum 1 Go. LES DONNÉES SERONT DETRUITES

    fdisk /dev/sdz    #on prépare la clé
    o      #nouvelle table de partition
    n       #nouvelle partition
    p       #partition primaire
    Entrée  -  Entrée               #garder les valeurs par défaut
    a       #rendre une partition active
    1       # ce sera la partition 1
    w       # on écrit les changement. Ceci détruit définitivement les données de la clé

    mkdosfs -F 32 /dev/sdz1         # on crée une partition FAT32

On peut désormais monter la clé, par nautilus, par la commande mount ou simplement en la débranchant/rebranchant

Récupérer l’archive boot.img.gz sur le site de Debian , la dézipper, la monter avec

mount /chemin/vers/boot.img -o loop /mnt
cp -R /mnt/* /media/VOTRE_CLE           # on copie tout le contenu de boot.img sur la clé

Copier également, à la racine, l’image iso que vous souhaitez installer (par exemple celle-ci ) . # Pour du amd64, prendre évidemment une iso amd64

Il suffit ensuite d’installer syslinux (bootloader spécial USB) sur la clé. Tout d’abord, il faut l’avoir sur son système : aptitude install syslinux mtools # mtools est nécessaire pour écrire sur les partitions FAT

Puis, si votre clé est /dev/sdz, fairee en root

umount /dev/sdz      # le reste se fait périphérique démonté
syslinux /dev/sdz1        # on peut passer l’option –simple pour un bootloader plus lent mais, parait-il, plus compatible
dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdz               # j’ai constaté, sous Debian Squeeze, que l’option -m pour écrire le mbr, préconisée sur les forums Ubuntu, n’avait aucun effet. On le copie donc à la main.

En bootant sur la clé, on arrive alors à l’install de Debian, qui est prévue pour détecter l’iso sur la clé :)

Cet article voit la configuration d’un serveur OpenVPN en mode routé, sur base d’un Debian Squeeze.

Le dossier de travail sera /etc/openvpn/easyrsa, dans lequel nous stockerons les variables, et les outils d’administrationdu serveur (et le fichier de configuration client exemple)

• Les clés (à garder secrètes) et certificats nécessaires seront stockées dans /etc/openvpn/easyrsa/keys

• La conf du serveur sera stockée directement dans /etc/openvpn, ce qui permettra un démarrage automatique du serveur

On y va. Tout est à faire en root

aptitude install openvpn
cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easyrsa
cd /etc/openvpn/esayrsa

#On définit les variables dans le fichier vars. Notez l’ajout d’un $OPENVPN_CLIENTS , qui va servir pour les scripts de gestion des users.
nano ./vars

# Les 5 champs à la fin du fichier vars nous interessent. Remplir avec ce que l’on souhaite.

# on initilalise les variables
. ./vars

# on clean et crée le repertoire de clés
./clean-all

#on crée la clé et le certif de l’autorité de certification (dans le cas présent, même machine que le serveur)
./build-ca

# on crée la clé du serveur, qu’on appelle server par facilité
./build-key-server server
#on peut tout laisser par défaut, et il n’est pas obligatoire de mettre un mot de passe. Juste répondre y aux 2 dernières questions

# on génère le paramètres Diffie Hellman – crypto, pour comprendre voir sur la wiki, mais il faut le faire
./build-dh

# on récupère la conf d’exemple du server
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gunzip /etc/openvpn/server.conf.gz

#et on peut la modifier. Le plus important est de donner le chemin complet aux fichiers certificats et clés server et CA. On peut aussi modifier l’adresse réseau qui servira pour le vpn. Il vaut mieux laisser udp (perf vpn). On peut spécifier un fichier pour les logs. Par défaut avec les bons chemins, le server est fonctionnel. Exemple (simplifié) ici : Fichier server.conf
nano /etc/openvpn/server.conf

# Puis on peut démarrer le server :
openvpn /etc/openvpn/server.conf
# Si la séquence se finit sur “Initialization Sequence Completed”, c’est gagné !