BxLUG groupe des utilisateurs de GNU/Linux de Bruxelles

Espace membres

OpenVPN : configuration d'un réseau privé virtuel

Résumé : Cet article a pour but de vous aider à configurer un réseau privé virtuel. Cela peut vous être utile si, par exemple, vous voulez accéder à votre serveur mail personnel depuis une machine dont l'accès à l'Internet est restreint par un pare-feu (au boulot par exemple). En particulier, ceci est utile aux «experts» du BxLUG pour accéder aux serveurs des écoles installés en Edubuntu. On initie des VPN automatiquement depuis les serveurs des écoles vers le serveur du BxLUG, et on peut ensuite y accéder depuis ce dernier, malgré les restrictions installées par le CIRB.

Software : OpenVPN 2.0 (license GPL v2)

Niveau de difficulté : moyen

Système d'exploitation du test :

1. Introduction

OpenVPN est un logiciel sous license libre GPL-v2 de déploiement de réseau privé virtuel (VPN - Virtual Private Network) qui permet aussi bien la configuration des machines clientes que des machines serveurs.

Le but d'un réseau privé virtuel est de permettre à un ordinateur qui se trouve sur l'Internet (Wide Area Network — WAN) d'être connecté de manière sécurisée à un réseau local d'ordinateurs (LAN) comme s'il était physiquement connecté au même switch ethernet que ces machines. Il devient alors possible à l'ordinateur distant d'accéder à tous les services normalement réservés aux seules machines connectées au réseau local et ceci quel que soit l'endroit d'où se connecte l'ordinateur distant.

Nous allons montrer comment mettre en place un réseau privé virtuel dans un but bien précis. Nous avons une machine, sur un réseau local, séparée de l'Internet par un pare-feu. Aucune connection depuis l'Internet ne peut être établie vers cette machine. Celle-ci peut par contre accéder de manière limité à l'Internet : essentiellement pour la consultation de pages webs. Notre but est de pouvoir accéder à cette machine depuis l'Internet sans aucune limitation. Pour y arriver, nous allons faire établir par cette machine une connection sur notre réseau privé virtuel. On pourra alors, via ce VPN, accéder sans aucune limitation à tous les ports de la machine.

2. Installation

Ubuntu étant basée sur Debian, elle en hérite des mêmes outils de configuration et des mêmes emplacements des fichiers de configuration. Tout ce qui est fait sur l'une peut l'être sur l'autre en reprenant les mêmes commandes et les mêmes fichiers de configuration, pour peu que leurs versions respectives ne soient pas trop éloignées chronologiquement.

L'installation se déroule très simplement en exécutant la commande suivante avec les droits d'administrateur : sous Debian, en étant root : 
        root@debserver:~# apt-get install openvpn
sous Ubuntu, en faisant précéder la commande par "sudo" : 
        gio@ubustation:~$ sudo apt-get install openvpn

3. Avant la configuration, la réflexion

Préalablement à la configuration, il est utile de se demander à quels besoins doit répondre notre réseau virtuel. Cela est important pour définir le système d'authentification que l'on va mettre en place ainsi que la manière dont le serveur va traiter le trafic réseau sur le VPNOpenVPN permet essentiellement deux types d'authentification. Une très simple basée sur une clé statique, une autre plus compliquée faisant appel à une infrastructure par clé publique (PKI -- Public Key Infrastructure). Les désavantages de la clé statique sont :

L'infrastructure par clé publique (PKI) ne connait pas ces limitations mais est moins facile à mettre en oeuvre.

Comme nous souhaitons étendre notre VPN à d'autres machines «enfermées» derrière un pare-feu, de manière sécurisée et sans devoir jouer avec l'ouverture de plusieurs ports sur notre serveur, nous allons mettre en place une infrastructure de type PKI.

En ce qui concerne la manière dont OpenVPN côté serveur gère le trafic réseau, deux méthodes sont envisageables : l'une "par pont" (bridging); l'autre "par routage" (routing). Dans la méthode "bridging", le fonctionnement du serveur est équivalent au fonctionnement d'un switch ethernet matériel. Les avantages de la méthode par "bridging" sont :

La méthode "bridging" nécessite l'établissement d'un pont entre l'interface réseau physique et l'interface réseau virtuelle. Cette configuration nécessite un outil approprié, peut être assez ennuyeuse à réaliser et passer par l'exécution de commandes pas toujours compréhensibles pour les initiés.

Les avantages majeures de la méthode "routing" sont une plus grande efficacité/performance et extensibilité que la méthode par "bridging", ainsi qu'une configuration plus facile. Les désavantages sont :

Nous allons configurer la méthode par "routing" car elle est simple à mettre en oeuvre (OpenVPN depuis la version 2.0 gère automatiquement l'attibution d'adresses aux clients ainsi que la configuration minimale des routes sur les clients) et répond pleinement à nos besoins.

4. Configuration de l'infrastructure par clé publique (PKI)

Nous allons mettre en place cette infrastructure en créant : Le "master CA" va servir à signer les certificats du serveur et des clients. Ainsi une authentification bidirectionnelle aura lieu :

Ainsi, le serveur ne devra plus stocker les clés publiques des clients, seul le certificat du CA sera nécessaire pour authentifier aussi bien les clients actuels que les futurs. Il suffira de signer la clé publique de tout nouveau client avec la clé privée du CA pour qu'il soit authorisé à se connecter au VPN. La clé privée du CA, qui est donc la donnée la plus sensible dans l'infrastructure, sera de préférence gardée en sécurité sur une machine non connectée au réseau.

copier le répertoire contenant les scripts dans votre répertoire de travail : 
        gio@debserver:~/openvpn$ cp /usr/share/doc/openvpn/examples/easy-rsa ~/openvpn/ -R
        gio@debserver:~/openvpn$ cd easy-rsa/2.0
éditer le fichier "vars" et remplacer les lignes suivantes selon votre cas : 
        export KEY_COUNTRY="BE"
        export KEY_PROVINCE="BXL"
        export KEY_CITY="Brussels"
        export KEY_ORG="BxLUG"
        export KEY_EMAIL="admin@bxlug.be"
exécuter les commandes suivantes pour initialiser les variables d'environnement et supprimer d'éventuelles anciennes clés : 
        gio@debserver:~/openvpn/easy-rsa/2.0$ . ./vars
        gio@debserver:~/openvpn/easy-rsa/2.0$ ./clean-all
A l'issue de la commande qui suit, des questions vous sont posées, acceptez les réponses par défaut sauf pour "Common Name" où vous choisirez un nom approprié pour votre "master CA". Nous avons choisis "BxLUG-CA" dans notre cas. 
        gio@debserver:~/openvpn/easy-rsa/2.0$ ./build-ca
        Generating a 1024 bit RSA private key
        .............++++++
        ...................................................................++++++
        writing new private key to 'ca.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) [BE]:
        State or Province Name (full name) [BXL]:
        Locality Name (eg, city) [Brussels]:
        Organization Name (eg, company) [BxLUG]:
        Organizational Unit Name (eg, section) []:
        Common Name (eg, your name or your server's hostname) [BxLUG CA]:BxLUG-CA
        Email Address [admin@bxlug.be]:
Les clés privée et publique générées sont copiées dans le répertoire "keys", respectivement "ca.key" et "ca.crt" . exécuter la commande suivante : 
        gio@debserver:~/openvpn/easy-rsa/2.0$ ./build-key-server bxlug-vpn-server
Remplacez "bxlug-vpn-server" par le nom de clé que vous voulez. Ici aussi des questions vous sont posées, acceptez les réponses par défaut sauf pour "Common Name" où vous choisirez un nom approprié, "bxlug-vpn-server" est probablement un bon choix dans notre cas. Deux questions vous sont ensuite posées "Sign the certificate? [y/n]" et "1 out of 1 certificate requests certified, commit? [y/n]", répondez aux deux par l'affirmative.Vos certificat et clé privée pour le serveur sont générés dans le répertoire "keys" avec le nom passé en paramètre à la fonction ci-dessus, dans notre cas respectivement "bxlug-vpn-server.crt" et "bxlug-vpn-server.key". exécuter les commandes suivantes : 
        gio@debserver:~/openvpn/easy-rsa/2.0$ ./build-key client1       
        gio@debserver:~/openvpn/easy-rsa/2.0$ ./build-key client2
De nouveau, acceptez les réponses par défaut sauf "Common Name" où vous choisirez probablement "client1" et "client2". Aux deux questions "Sign the certificate? [y/n]" et "1 out of 1 certificate requests certified, commit? [y/n]", répondez par l'affirmative.Vos certificats et clés privées pour les clients sont générés dans le répertoire "keys" respectivement "client1.crt/client2.crt" et "client1.key/client2.key" dans notre cas. exécuter la commande suivante : 
        gio@debserver:~/openvpn/easy-rsa/2.0$ ./build-dh
Les paramètres Diffie Hellman sont copiés dans le répertoire "keys" sous "dh1024.pem"On copiera les différents fichiers que nous venons de générér vers le répertoire "/etc/openvpn/keys" des machines concernées en suivant le tableau suivant :
Filename Needed By Purpose Secret
ca.crt server + all clients Root CA certificate NO
ca.key key signing machine only Root CA key YES
dhn.pem server only Diffie Hellman parameters NO
server.crt server only Server Certificate NO
server.key server only Server Key YES
client1.crt client1 only Client1 Certificate NO
client1.key client1 only Client1 Key YES
client2.crt client2 only Client2 Certificate NO
client2.key client2 only Client2 Key YES
Le répertoire "keys" devrait être rendu accessible à l'utilisateur root uniquement (permission 700). La clé "ca.key" devra être gardée en sécurité car elle sera nécessaire à chaque fois que l'on voudra générer et signer un certificat pour un nouveau client.

5 Configuration d' OpenVPN

Rappelez-vous notre but initial. Nous devons choisir un port par lequel notre machine pourra initié une connection vers notre serveur VPN. Une possibilité serait le port 443 ou HTTPS en TCP. Il est ouvert pour permettre l'accès à des pages web sécurisées. Nous allons cependant ci-dessous utilisé le port 1194, qui est le port standard pour OpenVPN et le protocole UDP recommandé. Il est bon de savoir que l'établissement d'un tunnel sur la couche TCP peut se traduire par une dégradation des performances. D'où la recommendation d'utiliser le protocole UDP.

récupérer le fichier exemple "server.conf" et mettez-le dans le répertoire "/etc/openvpn" du serveur: 
        root@debserver:/# cd /usr/share/doc/openvpn/examples/sample-config-files
        root@debserver:/# cp server.conf /etc/openvpn/server.conf
éditez le fichier "server.conf" dans "/etc/openvpn/" et assurez-vous que les lignes suivantes sont décommentées et ajustées à votre configuration: 
port 1194               # les clients se connecteront à ce port - votre firewall doit permettre cela
proto udp               # protocole utilisé dans la connexion
ca keys/ca.crt          # certificat du CA
cert keys/server.crt    # certificat du serveur
key keys/server.key     # clé privée du serveur
dev tun                 # méthode "routing"
dh keys/dh1024.pem      # paramètres Diffie Hellman
server 10.66.77.0 255.255.255.0         # sous-réseau que constituera le réseau virtuel
ifconfig-pool-persist ipp.txt           # permet de réattribuer la même adresse à chaque client
ping 10         # utile pour garder la connexion active au travers de certains types de firewall
ping-restart 60 # réinitialise la connexion si le délai est dépassé
comp-lzo        # compression des paquets
user nobody     # une fois démarré, l'appartenance du processus passe de l'utilisateur "root" à         
group nogroup   # "nobody" et du groupe "root" à "nogroup". Ainsi, si le processus est                  
                # compromis, aucun dommage ne pourra être causé avec les privilèges du                  
                # super-utilisateur
persist-key     # ne doit pas relire la clé en cas de réinitialisation de la connexion
persist-tun     # ne doit pas reconfigurer l'interface en cas de réinitialisation de la connexion
status openvpn-status.log # fichier de log
verb 3          # niveau de verbosité des log
vous pouvez à présent démarrer le serveur VPN par : 
        root@debserver:/etc/openvpn# openvpn server.conf
récupérer le fichier exemple "client.conf" et mettez-le dans le répertoire "/etc/openvpn" du client : 
        gio@ubustation:/$ cd /usr/share/doc/openvpn/examples/sample-config-files
        gio@ubustation:/$ sudo cp client.conf /etc/openvpn/
éditez le fichier "client.conf" dans "/etc/openvpn/" et assurez-vous que les lignes suivantes sont décommentées et ajustées à votre configuration: 
client                  # spécifie à openvpn de fonctionner en mode client
remote <adresse_ip_serveur_vpn> 1194
# adress_ip_serveur_vpn est soit l'IP du serveur, soit son nom d'hôte -- le firewall doit       
# permettre la connexion vers l'extérieur sur le port du serveur, ici 1194
proto udp               # protocole utilisé dans la connexion
resolv-retry infinite   # tentera indéfiniment de résoudre l'IP du serveur hôte en cas d'échec
nobind                  # spécifie de ne pas se lier à une adresse et un port local
ns-cert-type server     # vérifie que le certificat du serveur est bien un certificat de serveur et 
                        # ainsi évite de se connecter à un client qui se ferait passer pour le          
                        # serveur avec son certificat de client
ca keys/ca.crt          # certificat du CA
cert keys/client1.crt   # certificat du client1
key keys/client1.key    # clé privée du client1
dev tun                 # méthode par "routing"
comp-lzo        # compression des paquets
user nobody     # une fois démarré, l'appartenance du processus passe de l'utilisateur "root" à         
group nogroup   # "nobody" et du groupe "root" à "nogroup". Ainsi, si le processus est          
                # compromis, aucun dommage ne pourra être causé avec les privilèges du          
                # super-utilisateur
persist-key     # ne doit pas relire la clé en cas de réinitialisation de la connexion
persist-tun     # ne doit pas reconfigurer l'interface en cas de réinitialisation de la connexion
verb 3          # niveau de verbosité des log
vous pouvez à présent vous connecter au serveur VPN par : 
        gio@ubustation:/etc/openvpn$ sudo openvpn client.conf

6. Mot de la fin

Nous espérons que cet article vous aura permis de mettre en place votre réseau privé virtuel assez rapidement et sans difficulté. Si malgré tout, vous rencontrez des difficultés, nous vous renvoyons au site officiel (voir Ressources pour cet article) - HOWTO (2.0) - section "Starting up the VPN and testing for initial connectivity" pour une liste d'erreurs courantes et leur solution.

7. Ressources pour cet article

Bienvenue dans le monde du libre