Mise en place d'un VPN avec OpenVPN

Tuto plus du tout à jour

Prérequis

Pour commencer, il faut avoir installé openssl. Si ce n'est pas déjà fait :

aptitude install openssl

Ce tutoriel suppose que vous avez déjà mis en place une autorité de certification. Pour être précis, j'ai utilisé une autorité root root_ca, une première autorité intermédiaire onyx_ca, et enfin, une seconde autorité intermédiaire vpn_ca qui sera chargée de délivrer les certificats serveur et clients openvpn :

root_ca
 |-onyx_ca
   |-vpn_ca
     |-serveurVPN
     |-clientsVPN

• Le certificat de l'autorité root est /etc/ssl/root_ca/root_ca.pem
• Le certificat de l'autorité onyx est /etc/ssl/onyx_ca/onyx_ca.pem
• Le certificat de l'autorité vpn est /etc/ssl/vpn_ca/vpn_ca.pem

Pour de l'aide quant à la création de l'architecture d'une autorité de certification, rendez vous ici.

Installation

Installez openvpn avec aptitude :

aptitude install openvpn

Configuration du serveur openvpn

Génération des certificats

Modifiez votre fichier /etc/ssl/openssl.cnf en y ajoutant le bloc suivant :

[VPN_SERVER]
nsComment                       = "VPN Server Certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
nsCertType                      = server
extendedKeyUsage                = serverAuth

Nous allons maintenant générer le certificat du serveur openvpn puis le signer avec notre autorité vpn_ca :

openssl req -nodes -newkey rsa:2048 -keyout vpn.domain.tld.key -out vpn.domain.tld.req
openssl ca -name vpn_ca -extensions VPN_SERVER -in vpn.domain.tld.req -out vpn.domain.tld.pem

Puis générez votre clé Diffie-Hellman de 2048 bits:

openssl dhparam -out dh2048.pem 2048

Déplacez ces fichiers dans /etc/openvpn/ssl/ :

mkdir /etc/openvpn/ssl
mv vpn.domain.tld.* /etc/openvpn/ssl/
mv dh2048.pem /etc/openvpn/ssl/

Créez le fichier contenant la chaine de certification :

cat /etc/ssl/root_ca/root_ca.pem /etc/ssl/onyx_ca/onyx_ca.pem /etc/ssl/vpn_ca/vpn_ca.pem > /etc/openvpn/ssl/ca_chain.pem

Nous allons enfin générer une clé TLS pour bloquer les attaques DoS ainsi que le flood UDP en créant un firewall HMAC :

openvpn --genkey --secret /etc/openvpn/ssl/ta.key

Configuration de base de openvpn

Des exemples de configurations pour le serveur et le client openvpn se trouvent dans /usr/share/doc/openvpn/examples. Sur votre serveur, copiez l'exemple de configuration dans /etc/openvpn/ :

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gunzip /etc/openvpn/server.conf.gz

Voici par exemple mon fichier de configuration :

local 178.33.250.38
port 1194
proto udp
dev tun

#configuration ssl 
ca /etc/openvpn/ssl/ca_chain.pem
cert /etc/openvpn/ssl/vpn.domain.tld.pem
key /etc/openvpn/ssl/vpn.domain.tld.key
dh /etc/openvpn/ssl/dh2048.pem

#on va attribuer les ips vpn en 10.8.0.X
server 10.8.0.0 255.255.255.0

#stocker l'association entre un client et l'ip vpn. Ainsi, quand un client se reconnecte, il conservera la même ip vpn.
ifconfig-pool-persist ipp.txt

#la route doit être l'ip externe du serveur (si on veut utiliser la connexion de ce serveur)
;push "route 178.33.250.38 255.255.255.0"
#De même, force le client a rediriger son trafic vers le vpn (il faudra aussi faire un nat du range vpn (10.8.) vers internet (178.33.250.38)
;push "redirect-gateway def1 bypass-dhcp"

tls-auth /etc/openvpn/ssl/ta.key 0
comp-lzo
max-clients 10
user nobody
group nogroup
log-append  /var/log/openvpn.log

Définissez bien-sur l'ip de votre serveur à la ligne local. Vous noterez aussi que pour l'instant, la redirection du trafic (les lignes push) est désactivé.

N'autoriser que les certificats émis par vpn_ca

Pour l'instant, nous avons une configuration fonctionnelle, mais pas parfaite. En effet, nous avons créé une autorité de certification dédié à l'émission de certificats vpn, mais n'importe quel certificat signé par l'un des parents de cette autorité sera autorisé à se connecter. Par exemple, si vous signez un certificat client au moyen de l'autorité root_ca, ce certificat sera reconnu comme valide par openvpn (car du point de vue du protocole SSL, il l'est).

Si vous n'avez qu'un seul serveur cela ne devrait pas poser de problème. Mais si vous en avez plusieurs il est possible que l'autorité root_ca soit sur un serveur, alors que l'autorité vpn_ca soit sur un autre serveur, or, seul ce dernier serveur devrait être capable d'émettre un certificat client pour notre vpn (sinon, pourquoi créer tant d'autorités ? :)).
De même, le problème se pose si vous utilisez un certificat commercial que vous avez acheté (chez thawte par exemple). Étant donné que vous êtes obligé de préciser à openvpn le certificat root de thawte, toutes personnes ayant elle aussi un certificat thawte pourra se connecter à votre vpn (ce n'est pas exactement vrai étant donné que nous avons créé une clé tls propre à notre serveur (directive tls-auth)).

Pour régler ce problème, nous allons utiliser la directive tls-verify de openvpn qui permet de d'exécuter un script personnalisé afin d'autoriser ou de refuser la connexion selon le cas.

Ajoutez les lignes suivantes à votre fichier /etc/openvpn/server.conf :

script-security 2
tls-verify /etc/openvpn/allow.sh

Pour rappel, j'ai créé 3 autorités de certifications :

• root_ca, première autorité de certification, avec un certificat de profondeur 3
• onyx_ca, deuxième autorité de certification, avec un certificat de profondeur 2
• vpn_ca. troisième et dernière autorité de certification, avec un certificat de profondeur 1

Récupérez les noms complets de ces certificats dans les fichiers .pem correspondants (à la ligne subject:).

Note : la profondeur cité ici est de +1 par rapport à celle (pathlen) entrée dans la configuration openssl des certificats en question. En effet, openvpn considère le dernier certificat de la chaine (le certificat client ou serveur final) comme étant de profondeur 0, alors que pour openssl, un certificat serveur ou client n'a pas de profondeur).

Il va falloir modifier un peu ces noms afin qu'ils soient compréhensibles par openvpn :

• ajoutez un / au début
• remplacez tous les ", " (virgule suivi d'un espace) par un /
• remplacez tous les espaces à l'intérieur d'un champ par un _

Par exemple :

C=01, ST=Epsilon Eridani System, L=Reach, O=UNSC, OU=Office of Naval Intelligence, CN=UNSC VPN CA/emailAddress=plop@domain.tld

devient :

/C=01/ST=Epsilon_Eridani_System/L=Reach/O=UNSC/OU=Office_of_Naval_Intelligence/CN=UNSC_VPN_CA/emailAddress=plop@domain.tld

Créez le fichier /etc/openvpn/allow.sh contenant les lignes suivantes (adaptez la définissions des trois variables en fonction des noms des certificats que vous venez de transformer)  :

#! /bin/bash

depth_3="le_sujet_transformé_du_certificat_de_profondeur_3"
depth_2="le_sujet_transformé_du_certificat_de_profondeur_2"
depth_1="le_sujet_transformé_du_certificat_de_profondeur_1"

arg_depth=$1
arg_name=$2
eval a=\$depth_$arg_depth

#echo $a

#Si on est à la profondeur zéro, on est arrivé au certificat client
if [ $1 = 0 ]; then
        exit 0
fi

if [ "$a" = "$arg_name" ]; then
        exit 0
else
        exit 1
fi

Ce script va être exécuté par openvpn à chaque authentification et pour chaque certificat de la chaine de certification (quatre fois en tout dans notre cas : root_ca, onyx_ca, vpn_ca et le certificat client). Pour résumer lors d'une connexion au vpn :

• openvpn s'assure grâce à openssl que la chaine de certification est valide (c'est-à-dire, que tous les certificats sont valides l'un par rapport à l'autre).
• openvpn s'assure grâce à ce petit script que la chaine de certification est bien dans l'ordre que nous le voulons (root > onyx > vpn > client).

Ainsi, un certificat client émis par l'autorité root ou onyx se verra refuser la connexion, malgré qu'il soit valide du point de vue ssl.

Configuration du client openvpn

Tout d'abord, ajouter les lignes suivantes dans votre fichier /etc/ssl/openssl.cnf :

[VPN_CLIENT]
nsComment                       = "VPN CLIENT Certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation
nsCertType                      = client
extendedKeyUsage                = clientAuth

Générez et signez le certificat :

openssl req -nodes -newkey rsa:2048 -keyout client.key -out client.req
openssl ca -name vpn_ca -extensions VPN_CLIENT -in client.req -out client.pem

Récupérez les fichiers client.key et client.pem sur votre ordinateur, ainsi que le certificat de votre autorité root, et le fichier /etc/openvpn/ssl/ta.key. Placez les à l'abri dans un répertoire en limitant un maximum les droits (dans l'idéal, laissez juste les droits de lecteur à votre utilisateur).

KDE4 et networkmanager

Sur votre ordinateur, installez le paquet network-manager-openvpn-kde. Les dépendances nécessaires devraient s'installer.

Cliquez sur l'icone de networkmanager puis cliquez sur gérer les connexions.
Dans l'onglet VPN cliquez sur Ajouter puis sur OpenVPN.

Onglet OpenVPN

La passerelle est l'ip/hostname de votre serveur (celle que vous avez défini à la ligne local de la configuration de openvpn sur votre serveur). Les certificats à utiliser sont ceux que vous avez rapatrié juste avant.

Dans l'onglet Paramètres optionnels cochez la case compression lzo.

Dans l'onglet Paramètres TLS optionnels cochez la case utilisez une authentification TLS supplémentaire puis entrez le chemin vers la clé ta.key dans le champ Clé. Dans Direction de la clé sélectionnez 1.

Onglet Adresse IP

Cliquez sur la barre déroulante indiquant Réglage de base et sélectionnez Routes. Cochez la case Utilisez uniquement pour les ressources de cette connexion.

Rediriger certains ports vers le VPN

Modifications sur le serveur

Pour commencer, nous allons activer le forwarding ipv4. Modifiez le fichier /etc/sysctl.conf :

net.ipv4.ip_forward=1

Surtout ne touchez pas à net.ipv6.conf.all.forwarding

Validez vos modifications :

sysctl -p

Vous pouvez vérifier l'état du forwarding dans le fichier /proc/sys/net/ipv4/ip_forward

cat /proc/sys/net/ipv4/ip_forward

Il ne reste plus qu'a ajouter une règle iptables afin de rediriger le trafic vers l'une des ips de sortie de votre serveur (nat)

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j  SNAT --to-source <adresse ip>

Si vous préférez préciser l'interface plutôt que l'adresse ip :

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

A titre d'information, vous pouvez lister vos règles nat avec :

iptables -t nat --list

En cas d'erreur, vous pouvez remettre votre nat à zero avec :

iptables -t nat -F POSTROUTING

Modifications sur le client

Nous allons supposer que votre vpn vous a attribué l'ip 10.8.0.6 et que votre adresse ptp est 10.8.0.5.

Pour commencer, désactivez la validation d'adresse source sur l'interface vpn tun0 :

sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.tun0.rp_filter=0

Nous allons ensuite marquer les paquets reçus par l'interface eth0 destinés au port 80 (http) :

iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j MARK --set-mark 0x1

Nous faisons de même avec les paquets émis par le routeur vers internet :

iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set-mark 0x1

Ensuite, nous allons router les paquets marqués avec une table de routage alternative (100) qui ne sera utilisée que pour les paquets marqués :

ip rule add fwmark 0x1 table 100

Il faut ensuite créer une route par défaut pour la table alternative :

ip route add default dev tun0 via 10.8.0.5 table 100

Enfin, NATer l'adresse source avec l'adresse que notre vpn nous a attribué :

iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to 10.8.0.6

Rediriger la totalité de son trafic réseau vers le VPN

Modifications sur le serveur

Pour commencer, nous allons activer le forwarding ipv4. Modifiez le fichier /etc/sysctl.conf :

net.ipv4.ip_forward=1

Surtout ne touchez pas à net.ipv6.conf.all.forwarding

Validez vos modifications :

sysctl -p

Vous pouvez vérifier l'état du forwarding dans le fichier /proc/sys/net/ipv4/ip_forward

cat /proc/sys/net/ipv4/ip_forward

Il ne reste plus qu'a ajouter une règle iptables afin de rediriger le trafic vers l'une des ips de sortie de votre serveur (nat)

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j  SNAT --to-source <adresse ip>

Si vous préférez préciser l'interface plutôt que l'adresse ip :

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

A titre d'information, vous pouvez lister vos règles nat avec :

iptables -t nat --list

En cas d'erreur, vous pouvez remettre votre nat à zero avec :

iptables -t nat -F POSTROUTING

Modifications sur le client

KDE4 et networkmanager

Dans l'onglet adresse ip, cliquez sur la barre déroulante indiquant Réglage de base et sélectionnez Routes. Décochez la case Utilisez uniquement pour les ressources de cette connexion.