On cherche à connecter un poste client au travers d'un réseau non sécurisé au serveur. Un hôte virtuel apache associée à l'interface loopback du serveur sera accessible.

Ajout temporarie d'une IP sur l'interface loopback

$ sudo ip addr add

Installer les paquets openvpn easy-rsa

$ sudo apt-get install openvpn easy-rsa

easy-rsa contient un ensemble de scripts assistant la génération des certificats serveur et clients.

$ cd /user/share/easy-rsa
# Configuration
$ sudo vim vars

...

# sourcer le fichier définissant les variables
source ./vars
# par précaution supprimer les fichiers temporaires
./clean-all
# construire clés et certificat pour l'autorité de certification racine
./build-ca

Après validation des valeurs par défaut, les fichiers suivants ont été créés dans le repertoire ./keys:

• ca.key: la clé privée de l'autorité de certification racine.
• ca.crt: le certificat de l'autorité de certification racine.
• index.rxt la liste des certificats OpenSSL
• serial identifiant du dernier certificat émis

Le certificat de l'autorité de certification racine exisant, on peut générer les clés et certificat pour le serveur et les clients:

Pour le serveur:

./build-key-server servername

Pour chaque client on générera un clé:

./build-key client-name

Génération du fichier dhparam pour l'échange de clés. Basé sur l'algorithme Diffie-Hellman, la génération peut prendre un certain temps.

./build-dh

Créer le dossier /etc/openvpn/keys et y copier:

• Le certificat de l'autorité de certification racine.
• Le certificat serveur.
• La clé privée du serveur.
• Le fichier dh2048.pem.

mkdir /etc/openvpn/keys
cp keys/ca.crt keys/severname.crt keys/servername.key keys/df2048.pem /etc/openvpn/keys

Créer le fichier de configuration du serveur /etc/openvpn/server.conf avec le contenu suivant:

server.conf

mode server
proto udp
dev tun
topology subnet
ca keys/ca.crt
cert keys/ovpngw.crt
key keys/ovpngw.key
dh keys/dh2048.pem
server 10.50.0.0 255.255.255.0
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

A propos des directives du fichier ci-dessus:

• dev tun Création d'un tunnel au niveau 3 OSI (encapsulation du protocole au niveau du routage IP).

• topology subnet la topologie par défaut net30 est inutile ici. Beaucoup plus complexe, net30 offre de la rétrocompatibilité avec les machines Windows.
• server 10.50.0.0. 255.255.255.0 cette seule directive aura pour conséquences:
  • De passer en mode sécurisé TLS
  • De fournir automatiquement la topologie définie plus haut aux clients
  • Initialiser automatiquement les paramètres réseau serveur et clients ici les adresses du réseau 10.50.0/24 seront utilisées.
• keepalive 10 120 renvoi un ping après 10 secondes d'inactivité et relancer la connexion après 120 secondes sans activité.
• persist-key pas de renégociation après redémarrage de connexion.
• persist-tun pas de fermeture/réouverture du device tun à chaque redémarrage de connexion.

Vérifier que la machine agira bien en passerelle en transmettant les paquets entre ces différentes interfaces. Vérifier la configuration du noyau:

cat /proc/sys/net/ipv4/ip_forward
1

Si la valeur 1 n'est pas retournée, modifier le fichier /etc/sysctl.conf. Confère wiki

Démarrage manuel du serveur:

cd /etc/openvpn
openvpn --config server.conf

Le fonctionnement normal du serveur retournera sur la console:

... Initialization Sequence Completed

client
dev tun
proto udp
remote 192.168.1.99 1194
nobind
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client-name1.crt
key /etc/openvpn/keys/client-name1.key
comp-lzo
verb 3

Lancement manuel du client de la même façon que coté serveur:

cd /etc/openvpn
openvpn --config client.conf

A ce stade, la connexion est fonctionnelle.

Lors de l'établissement de la liaison les logs mettent en avant:

• Que méthode de chiffrement (cipher BF-CBC 128 bits) est relativement faible et peut être améliorée.
• Que l'algorithme d'authentification SHA-1 peut être modifié car considéré peu fiable à ce jour.
• Le warning “No server certificate verification method has been enabled” indique que le client n' a fait qu'une vérification partielle du certificat fournit par le serveur pouvant conduire a une attaque man in the middle. Pour une vérification en profondeur, ajouter la directive remote-cert-tls server dans la configuration client.

Le tunnel est fonctionnel mais coté client les routes n'ont pas été mises a jour. Pour que le réseau soit accessible au client, il faut déclarer au serveur les routes qu'il doit mettre a jour sur le client pour que celui-ci puisse accéder au sous réseau.