Avec un minimum de matériel, il est possible de réaliser une architecture sécurisée et fiable.Ainsi bien qu’ayant un abonnement carte SIM délivrant une ip privée, vous pourrez accéder à vos équipements via votre serveur Linux. Attention que le port 1194 (OpenVPN par défaut) ne soit pas filtré par votre abonnement opérateur, dans ce cas, utiliser un autre port, par exemple 9300 (côté LS300 et Serveur).

Exemple d’architecture composée de deux réseaux distants :

Principe de fonctionnement

OpenVPN fonctionne sur le modèle “ Client / Serveur ” :

L’un des bouts du tunnel sera serveur (Linux), à savoir qu’il restera en permanence à l’écoute sur un port UDP (ici 1194), il doit bien entendu être joignable par une adresse IP fixe publique,
L’autre bout du tunnel sera un client (LS300), il décidera quand il veut établir le tunnel et n’aura pas besoin de disposer d’une adresse IP fixe publique. Mieux, même si son IP change alors que le tunnel est établi, OpenVPN saura gérer cette situation.,
Un jeux de clés et certificats : cela est conforme au fonctionnement du SSL/TLS,
Une configuration valide de type “ Serveur ”,
Une configuration valide de type “ Client ”.

Installation d’OpenVPN

Installez OpenVPN, bien souvent disponible dans les dépôts de base de votre distribution.

Attention, tout le processus doit s’effectuer connecté en administrateur “root”.

En fonction de votre distribution, les commandes peuvent être différentes…

Installation d’OpenVPN
> apt-get install openvpn easy-rsa

Génération des certificats et clés d’authentification OpenVPN

OpenVPN peut fonctionner avec plusieurs types d’authentification.

Nous utiliserons l’authentification par clés et certificats, plus sûre que le classique couple “identifiant / mot de passe”.

L’installation d’OpenVPN crée un dossier dans /usr/share/doc/openvpn/easy-rsa/ contenant tous les scripts permettant de générer facilement tous les certificats et clés d’authentification nécessaire au fonctionnement d’OpenVPN.

Avant toute chose, créez un dossier easy-rsa dans le répertoire d’OpenVPN et copier les scripts originaux dedans afin de centraliser applications et scripts :

Création du répertoire et copie des scripts
> mkdir /etc/openvpn/easy-rsa
> cp -r /usr/share/easy-rsa /etc/openvpn/easy-rsa/

On crée ensuite un dossier keys destiné à contenir les différents certificats et clés générés :

Création du répertoire clés et certificats
> mkdir /etc/openvpn/keys/

Initialisation des variables de génération

A partir du dossier /etc/openvpn/easy-rsa/, il faut dans un premier temps éditer le fichier vars afin d’initialiser différentes variables servant à la génération des certificats :

Edition du fichier vars
> gedit /etc/openvpn/easy-rsa/vars

Adaptez le fichier vars avec vos informations personnelles :

Informations du fichiers vars
> export KEY_COUNTRY=”FR”
> export KEY_PROVINCE=”FR”
> export KEY_CITY=”NANTES”
> export KEY_ORG=”SPHINX”
> export KEY_EMAIL=”support@sphinxfrance.fr”

Puis exécutez le script afin d’initialiser les variables :./

Exécution du scripts vars
> . ./vars

Génération du certificat et de la clé d’autorité de certification

OpenVPN fonctionne sous un mode PKI (Public Key Infrastructure). Selon ce mode, le serveur et chaque client possède un certificat (appelé également clé publique) et une clé privée qui leur sont propres. Un certificat d’autorité de certification (master CA) et une clé privée sont utilisés pour signer les certificats du serveur et de chaque client. Ce master CA permet une authentification bidirectionnelle : chacun des clients et serveur authentifient donc l’autre réciproquement en vérifiant dans un premier temps que le certificat qu’ils proposent a bien été signé par le master CA.

Pour générer ce master CA et la clé correspondante, il faut exécuter les scripts suivants à partir du dossier/etc/openvpn/easy-rsa :

Exécution des scripts clean-all & build-ca
> ./clean-all
> ./build-ca

L’exécution du script build-ca entraîne la création du certificat ca.crt (1) et de la clé ca.key dans le répertoire/etc/openvpn/easy-rsa/keys.

Génération du certificat et de la clé pour le serveur

La génération du certificat et de la clé du serveur VPN se fait simplement, par l’exécution du script build-key-server, toujours à partir du dossier /etc/openvpn/easy-rsa

Attention : La commande d’éxecution du script build-key-server doit être suivie d’un nom donné au serveur. Ce nom n’a pas d’importance en soit, il peut être ce que vous voulez. L’important est de toujours utiliser le même nom quand celui-ci est demandé ! Dans notre ex : lubuntu

Génération certificat et clé serveur
> ./build-key-server lubuntu

Différentes informations sont demandées pendant l’exécution de ce script :

« Sign the certificate ? » : tapez “yes”

« 1 out of 1 certificate requests certificated, commit » : tapez “yes”

Ce script conduit à la création des fichiers lubuntu.crt et lubuntu.key dans le dossier/etc/openvpn/easy-rsa/keys.

Génération des certificats et clés pour le client1

De la même façon, ils sont générés par l’exécution du script build-key à partir du dossier /etc/openvpn/easy-rsa/ :

Attention : Encore une fois, de même manière que pour le serveur, l’exécution du script build-key demande d’entrer le nom du client ! Dans notre exemple : client1

Génération certificat et clé pour le client1
> ./build-key client1

Répétez cette opération autant de fois que vous voulez pour générer plusieurs certficats et clés si vous avez plusieurs clients. N’oubliez pas cependant de changer de nom_du_client à chaque fois !!!

Ce script entraine la création des fichiers client1.crt (2) et client1.key (3) dans le dossier/etc/openvpn/easy-rsa/keys.

Si votre architecture comporte plusieurs LS300 clients alors vous devez avoir des réseaux différents pour chaque site distant. Dans notre exemple, un seul LS300 en ip usine 192.168.13.31/24.

Génération des paramètres de Diffie-Hellman

Le protocole Diffie-Hellman est un protocole de cryptographie utilisé dans les échanges de clés, pour de plus amples informations, merci de vous rendre sur la page de Wikipedia traitant ce sujet.

Les paramètres de Diffie-Hellman sont générés par l’exécution du script build-dh à partir du dossier/etc/openvpn/easy-rsa :

Génération des paramètres de Diffie-Hellman
> ./build-dh

L’exécution provoque en sortie un message de ce style :

Sortie de l’exécution de Diffie-Hellman
> Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
……………..+…………………………………….
……………….+………….+……………..+………
………………………………..

Il en résulte la création du fichier dh2048.pem dans le dossier /etc/openvpn/easy-rsa/keys.

Résumé des fichiers créés

Au terme de la génération de ces diverses clés et certificats, nous obtenons les fichiers suivants :

sous /etc/openvpn/easy-rsa/keys/

ca.crt : certificat de l’Autorité de Certification (1)
ca.key : clé de l’Autorité de Certification
lubuntu.crt : certificat du serveur
lubuntu.key : clé du serveur
client1.crt : certificat du client1 (2)
client1.key : clé du client1 (3)
dh2048.pem : paramètres de Diffie-Hellman

.crt et .pem= fichiers qui ne sont pas secrets, .key= fichiers secrets.

Attention toute particulière au fichier ca.key, notez que ce fichier n’est nécessaire ni sur le serveur, ni chez aucun client mais il sert à signer tous les certificats et permet d’autoriser ou non un client, et il est donc fondamental qu’il soit gardé secret !

En pratique, les fichiers nécessaires sont :

Serveur : ca.crt, lubuntu.crt, lubuntu.key, dh2048.pem
Client1 : ca.crt, client1.crt, client1.key

Copie des fichiers sur le Serveur

Copie des fichiers côté Serveur
> cp /etc/openvpn/easy-rsa/keys/ca.crt /etc/openvpn> cp /etc/openvpn/easy-rsa/keys/lubuntu.crt /etc/openvpn> cp /etc/openvpn/easy-rsa/keys/lubuntu.key /etc/openvpn> cp /etc/openvpn/easy-rsa/keys/dh2048.pem /etc/openvpn

Configuration d’OpenVPN

La création des clés et certificats d’authentification est terminée. Nous allons passé à la configuration du serveur et des clients. Afin de configurer au mieux le serveur et les clients, il est nécessaire de préparer le terrain. Des exemples de fichiers de configuration sont présents dans le dossier /usr/share/doc/openvpn/examples/sample-config-files/.

Dans notre cas, nous allons créer et commenter directement les fichiers à mettre en oeuvre pour l’utilisation avec le Sierra LS300.

Configuration du serveur Linux

Il suffit de renseigner les bons paramètres au fichier /etc/openvpn/server.conf

Voila, la configuration du côté serveur est terminée !

Pour démarrer le serveur, la commande est :

Démarrage du serveur OpenVPNPour qu’OpenVPN se lance au démarrage du serveur, il faut placer le fichier de configuration au bon endroit /etc/openvpn. Dans notre cas, seul un rédémarrage du serveur ou du service est nécessaire.

Sinon, via le répertoire /etc/openvpn/ pour visualiser le log de connexion
> openvpn server.conf&

root@lubuntu:/etc/openvpn# Mon Dec 8 09:55:14 2014 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL]
[PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Mon Dec 8 09:55:14 2014 Diffie-Hellman initialized with 2048 bit key
Mon Dec 8 09:55:14 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Mon Dec 8 09:55:14 2014 ROUTE_GATEWAY 192.168.30.6/255.255.255.0 IFACE=eth0 HWADDR=ea:44:90:c9:95:b0
Mon Dec 8 09:55:14 2014 TUN/TAP device tun0 opened
Mon Dec 8 09:55:14 2014 TUN/TAP TX queue length set to 100
Mon Dec 8 09:55:14 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Dec 8 09:55:14 2014 /sbin/ip link set dev tun0 up mtu 1500
Mon Dec 8 09:55:14 2014 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Mon Dec 8 09:55:14 2014 /sbin/ip route add 192.168.13.0/24 via 10.8.0.2
Mon Dec 8 09:55:14 2014 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Mon Dec 8 09:55:14 2014 UDPv4 link local (bound): [undef]
Mon Dec 8 09:55:14 2014 UDPv4 link remote: [undef]
Mon Dec 8 09:55:14 2014 MULTI: multi_init called, r=256 v=256
Mon Dec 8 09:55:14 2014 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Mon Dec 8 09:55:14 2014 ifconfig_pool_read(), in=’client1,10.8.0.4′, TODO: IPv6
Mon Dec 8 09:55:14 2014 succeeded -> ifconfig_pool_set()
Mon Dec 8 09:55:14 2014 IFCONFIG POOL LIST
Mon Dec 8 09:55:14 2014 client1,10.8.0.4
Mon Dec 8 09:55:14 2014 Initialization Sequence Completed
Mon Dec 8 09:55:16 2014 176.178.139.10:52220 TLS: Initial packet from [AF_INET]176.178.139.10:52220, sid=6c66b324 81022f75
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 VERIFY OK: depth=1, C=FR, ST=FR, L=NANTES, O=SPHINX, OU=MyOrganizationalUnit, CN=SPHINX CA, name=EasyRSA, emailAddress=support@sphinxfrance.fr
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 VERIFY OK: depth=0, C=FR, ST=FR, L=NANTES, O=SPHINX, OU=MyOrganizationalUnit, CN=client1, name=EasyRSA, emailAddress=support@sphinxfrance.fr
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 Data Channel Encrypt: Cipher ‘BF-CBC’ initialized with 128 bit key
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 Data Channel Encrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 Data Channel Decrypt: Cipher ‘BF-CBC’ initialized with 128 bit key
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 Data Channel Decrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Mon Dec 8 09:55:23 2014 176.178.139.10:52220 [client1] Peer Connection Initiated with [AF_INET]176.178.139.10:52220
Mon Dec 8 09:55:23 2014 client1/176.178.139.10:52220 OPTIONS IMPORT: reading client specific options from: ccd/client1
Mon Dec 8 09:55:23 2014 client1/176.178.139.10:52220 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Mon Dec 8 09:55:23 2014 client1/176.178.139.10:52220 MULTI: Learn: 10.8.0.6 -> client1/176.178.139.10:52220
Mon Dec 8 09:55:23 2014 client1/176.178.139.10:52220 MULTI: primary virtual IP for client1/176.178.139.10:52220: 10.8.0.6
Mon Dec 8 09:55:23 2014 client1/176.178.139.10:52220 MULTI: internal route 192.168.13.0/24 -> client1/176.178.139.10:52220
Mon Dec 8 09:55:23 2014 client1/176.178.139.10:52220 MULTI: Learn: 192.168.13.0/24 -> client1/176.178.139.10:52220
Mon Dec 8 09:55:26 2014 client1/176.178.139.10:52220 PUSH: Received control message: ‘PUSH_REQUEST’
Mon Dec 8 09:55:26 2014 client1/176.178.139.10:52220 send_push_reply(): safe_cap=940
Mon Dec 8 09:55:26 2014 client1/176.178.139.10:52220 SENT CONTROL [client1]: ‘PUSH_REPLY,route 192.168.30.0 255.255.255.0,route 10.8.0.1,topology net30,ping 600,ping-restart 1800,ifconfig 10.8.0.6 10.8.0.5’ (status=1)

Vous pouvez vérifier que tout s’est bien passé jusqu’à présent en vérifiant la création et la bonne configuration de l’interface tun0 :

Affichage des interfaces réseau
> ifconfig

Vous devriez avoir quelque-chose dans ce style :

Exemple d’interface
> tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.0.1 P-t-P:10.8.0.2 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
Packets reçus:2 erreurs:0 :0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
Octets reçus:168 (168.0 B) Octets transmis:168 (168.0 B)

Configuration du client LS300

Pour fonctionner, le LS300 a besoin de 3 fichiers provenant du serveur (voir 2.6).

Récupérez et transférer les fichiers suivants du serveur /etc/openvpn/easy-rsa/keys/ vers le LS300

ca.crt (1)
client1.crt (2)
client1.key (3)

Voici la configuration de la page VPN du LS300

Vérification

Côté Client depuis sur PC sur le réseau du LS300

Ping de l’adresse IP OpenVPN du serveur Linux

Ping serveur 10.8.0.1
> ping 10.8.0.1

PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_req=1 ttl=63 time=87.4 ms
64 bytes from 10.8.0.1: icmp_req=2 ttl=63 time=75.6 ms
64 bytes from 10.8.0.1: icmp_req=3 ttl=63 time=93.9 ms
^C
— 10.8.0.1 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 75.694/85.689/93.901/7.539 ms

ou affichage du fichier /etc/openvpn/openvpn-status.log

Côté Serveur (Linux)

Ping de l’adresse IP OpenVPN du Client

Ping client1 10.8.0.6

PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data.
64 bytes from 10.8.0.6: icmp_req=1 ttl=64 time=571 ms
64 bytes from 10.8.0.6: icmp_req=2 ttl=64 time=524 ms
64 bytes from 10.8.0.6: icmp_req=3 ttl=64 time=570 ms
64 bytes from 10.8.0.6: icmp_req=4 ttl=64 time=518 ms
^C
— 10.8.0.6 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 518.107/546.033/571.512/24.887 ms

ou affichage du fichier /etc/openvpn/openvpn-status.log

Affichage des logs de connexion
> cat /etc/openvpn/openvpn-status.log

OpenVPN CLIENT LIST
Updated,Tue Jan 7 16:00:42 2014
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1,80.215.97.6:43551,106188,112630,Tue Jan 7 12:40:08 2014
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
192.168.13.100C,client1,80.215.97.6:43551,Tue Jan 7 15:59:49 2014
192.168.13.0/24,client1,80.215.97.6:43551,Tue Jan 7 12:40:23 2014
10.8.0.6,client1,80.215.97.6:43551,Tue Jan 7 16:00:14 2014
GLOBAL STATS
Max bcast/mcast queue length,0
END

Inclure des machines côté LAN

5.1 – Activation de l’IP Forwarding côté Serveur

Activation forwarding

> cat /proc/sys/net/ipv4/ip_forward
0 (indique non activé)

# activer via la commande

> echo 1 > /proc/sys/net/ipv4/ip_forward

# ou via fichier /etc/sysctl.conf
# décommenter la ligne net.ipv4.ip_forward=1

Inclure des machines côté Client LS300

Le but étant que chaque machine du réseau client communique avec chaque machine du réseau serveur à travers le VPN

le sous-réseau client doit être unique (192.168.13.0/24) dans notre exemple
le “common-name” doit être unique et le marqueur “duplicate-cn” permettant d’avoir des clients avec le même nom) ne doit pas être utilisé dans le fichier de configuration du serveur OpenVPN.

Créer le fichier CCD

Répertoire CCD (client)

# Créer le répertoire CCD
> mkdir /etc/openvpn/ccd
# Décommenter la ligne client-config-dir ccd dans le fichier /etc/openvpn/server.conf (voir section 3.1)
client-config-dir ccd

Créer un fichier client1 sous le répertoire ccd

iroute 192.168.13.0 255.255.255.0

Ceci permet d’indiquer au serveur OpenVPN que le sous-réseau 192.168.13.0/24 peut être routé vers le client1. Dans le fichier de configuration du serveur /etc/openvpn/server.conf (et non dans ccd/client1), il faut vérifier la présence de la ligne :

# Décommenter la ligne dans le fichier /etc/openvpn/server.conf (section 3.1)
route 192.168.13.0 255.255.255.0

Pourquoi mettre des informations redondantes ? « route » contrôle le routage dans le noyau vers le serveur OpenVPN (via l’interface tun) alors que «iroute» contrôle le routage depuis le serveur OpenVPN vers le client distant. Les deux sont nécessaires.

Les communications entre le LAN côté Client LS300 et les machines du réseau Serveur doivent fonctionner…

Ping LAN client depuis Serveur
IP du LS300
root@lubuntu:~# ping 192.168.13.31
PING 192.168.13.31 (192.168.13.31) 56(84) bytes of data.
64 bytes from 192.168.13.31: icmp_seq=1 ttl=64 time=86.8 ms
64 bytes from 192.168.13.31: icmp_seq=2 ttl=64 time=76.1 ms
64 bytes from 192.168.13.31: icmp_seq=3 ttl=64 time=85.1 ms
64 bytes from 192.168.13.31: icmp_seq=4 ttl=64 time=79.6 ms
64 bytes from 192.168.13.31: icmp_seq=5 ttl=64 time=97.3 ms
64 bytes from 192.168.13.31: icmp_seq=6 ttl=64 time=127 ms
64 bytes from 192.168.13.31: icmp_seq=7 ttl=64 time=127 ms

IP PC réseau
root@lubuntu:~# ping 192.168.13.100
PING 192.168.13.100 (192.168.13.100) 56(84) bytes of data.
64 bytes from 192.168.13.100: icmp_seq=3 ttl=63 time=103 ms
64 bytes from 192.168.13.100: icmp_seq=4 ttl=63 time=86.4 ms
64 bytes from 192.168.13.100: icmp_seq=5 ttl=63 time=83.6 ms
64 bytes from 192.168.13.100: icmp_seq=6 ttl=63 time=83.7 ms
64 bytes from 192.168.13.100: icmp_seq=7 ttl=63 time=84.6 ms

Conclusion

Votre configuration doit être fonctionnelle…

Pour plus de détails, consultez les manuels d’OpenVPN au lien suivant : documentation officielle

Merci et bon tunnel à tous…….

Sphinx décline toute responsabilité quant à l’utilisation des informations contenues dans ce document. Celles-ci sont uniquement fournies à titre informatif et n’entraînent aucune obligation légale.

Créer un tunnel sécurisé entre une gateway et un serveur OpenVPN Linux