Published using Google Docs
10 Fiche OpenVPN // Client Airlink & Lubuntu Server 14.04.1
Updated automatically every 5 minutes

maj 08/12/2014


SSL Tunnel (OpenVPN)

LS300 Client / Linux Lubuntu Serveur 14.04 -LTS


1 - Installation d’OpenVPN

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

2.1 - Initialisation des variables de génération

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

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

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

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

2.6 - Résumé des fichiers créés

2.7 - Copie des fichiers sur le Serveur

3 - Configuration

3.1 - Configuration du serveur Linux

3.2 - Configuration du client LS300

4 - Vérification

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

4.2 - Côté Serveur (Linux)

5 - Inclure des machines côté LAN

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

5.2 - Inclure des machines côté Client LS300

6 - Conclusion

Un tunnel SSL permet à des équipements de communiquer ensemble à travers un réseau sécurisé via internet.

SSL est basé sur le “package” OpenVPN.

Avec OpenVPN, vous pouvez choisir entre un tunnel IP (pilote TUN) ou Ethernet (pilote TAP).

Le tunneling IP est également appelé mode de routage tandis que le tunneling Ethernet est aussi appelé mode pont (bridging).  

Le LS300 ne supporte que le mode client TUN (routing) via UDP.

LS300 étant simplement client SSL, il devra communiquer avec un Serveur SSL lui aussi basé sur OpenVPN.

Dans notre cas :

Client, LS300, firmware version 4.4.0.011

Serveur, Linux Lubuntu, version 14.04.1 LTS kernel 3.13.0.40-generic

https://help.ubuntu.com/community/Lubuntu/GetLubuntu/14.04.1

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 ” :


1 - 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

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

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épértoire 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/

2.1 - 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

2.2 - 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.

2.3 - 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.

2.4 - 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.

2.5 - 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.

2.6 - 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/

En vert, les fichiers qui ne sont pas secrets, en rouge les 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 :

2.7 - 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

3 - Configuration

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.

3.1 - Configuration du serveur Linux

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

Explication du contenu du server.conf

# numéro de port utilisé

port 1194

# protocole de communication

proto udp

# type d’interface

dev tun

# emplacement du master CA

ca /etc/openvpn/ca.crt

# emplacement du certificat serveur

cert /etc/openvpn/lubuntu.crt

# emplacement de la clé serveur

key /etc/openvpn/lubuntu.key 

# emplacement du fichier Diffie-Hellman

dh /etc/openvpn/dh2048.pem

# réseau du serveur OpenVPN, l’adresse du serveur sera 10.8.0.1

server 10.8.0.0 255.255.255.0

# Ajout de la prise en charge des fichiers de configuration client, décommenter ci dessous pour inclure des machines côté LAN.

# client-config-dir ccd

# Décommenter ci dessous pour ajout d’une route vers le réseau distant client1

# route 192.168.13.0 255.255.255.0

# envoie d’une route du réseau serveur vers le client1

push “route 192.168.1.0 255.255.255.0

# fichier de réservation IP

ifconfig-pool-persist ipp.txt

# vérifie le tunnel toutes les 600sec et déconnecte si pas de réponse au bout de 30 minutes.

keepalive 600 1800

# Type d’encryptage des données Blowfish

cipher BF-CBC      

# activation de la compression

comp-lzo

# protocole d’authentification

auth SHA1

# paramètres avancés

tun-mtu 1500

fragment 1300

mssfix 1400

# pour rendre la connexion permanente

persist-key

persist-tun

# fichier de log

status openvpn-status.log

# niveau de verbosité les logs

verb 3

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

Pour démarrer le serveur, la commande est :

Démarrage du serveur OpenVPN

Pour 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 tun

> 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)

3.2 - 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

Voici la configuration de la page VPN du LS300

4 - Vérification

4.1 - 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

4.2 - Côté Serveur (Linux)

Ping de l’adresse IP OpenVPN du Client

Ping client1 10.8.0.6

> ping 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

5 - 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

5.2 - 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

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

Fichier Client1 sous 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 :

Fichier server.conf

# 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

6 - 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.