Présentation

Un VPN est un tunnel entre deux réseaux privé, il permet à des gens de travailler de chez eux dans les mêmes conditions qu’au travail.

Présentation du contexte

Au début de ce TP , nous avons nos deux machines dans le même réseaux. Plus tard notre client sera en dehors de notre réseau.

Installation

On va installer trois paquets, on commence comme d’habitude par un  » apt-get update « . Puis un  » apt install openvpn openssl wireshark « 
Les deux premiers paquets vont nous servir à créer le VPN, le troisième va nous permettre de capturer les échanges et de les examiner.

Utilisation d’openvpn en ligne de commande.

Nous allons commencer par utiliser openVPN en ligne de commande avec le service arrêté.
Sur notre serveur openvpn nous tester d’ouvrir un tunnel sans cryptage avec la ligne de commande suivante :
openvpn –dev tun0 –verb 5–ifconfig 10.0.0.1 10.0.1.2
— dev = l’interface virtuelle utilisé , — verb permet d’indiquer le niveau de log et — ifconfig indique dans la connexion point à point les deux adresse.

Sur notre client vpn , nous allons lancer la commande suivante pour établir la connexion :

Openvpn –dev tun0 –verb 5 –ifconfig 10.0.1.2 10.0.0.1 –remote 172.16.3.97
— remote
indique l’adresse ip du serveur VPN.

Une fois les deux commande lancé , nous utilisons wireshark pour capturer les trames qu’on va envoyer à partir du client sur l’adresse IP 10.0.0.1

Création du certificat.

Nous avons vu l’établissement de connexion sans cryptage, nous allons maintenant voire la génération de certificat et comment les utiliser.
Dans notre TP , il nous est demandé de créer une arborescence spécial pour openvpn à savoir :

  • /apps/openvpn/keys/
  • /apps/openvpn/log
  • /apps/openvpn/conffiles
  • /apps/easy-rsa.

Nous allons copier le contenue de « /usr/share/easy-rsa/* » dans « /apps/easy-rsa ».
Nous allons modifier le fichier vars de cette façon :


Nous indiquons où vont être stockés les certificats créés plus tard. Les autres lignes servent à pré-renseigner la création d’un certificat.

Il existe un problème connu depuis longtemps sur openVPN qui est qu’openssl.cnf n’est pas défini nativement. Nous allons copier openssl-1.0.0.cnf pour avoir un back-up et renommer le fichier original en openssl.cnf

La commande  source vars, permet d’utiliser les configuration saisi par l’utilisateur dans le fichier vars.
Nous allons générer le certificat racine avec le script   ./build  -ca en se trouvant dans le répertoire  /apps/easy-rsa   et répondre à toutes ces questions.
Nous allons générer le certificat du serveur avec le script ./build-key-server ‘nomduserver’ (dans mon cas Debian) et on va créer celui du client avec le script ./build-key ‘nomduclient’ (dans mon cas client-linux).
Nous allons maintenant créer le clé DH avec le script ./build-dh  , Cette clé sert à la sécurisation des échanges.

Configuration du Serveur.

Nous allons créer le fichier de configuration pour le service openvpn, logiquement il se trouve dans /etc/openvpn, mais nous allons le créer dans notre arborescence en /apps/openvpn/conffiles .

On redémarre le service openVPN

Nous allons lancer le ficher de configuration et les logs en même temps.

La ligne « Initialization Sequence Completed » nous indique que tout s’est bien passé.

Configuration du Client.

Nous devons rapatrier les certifcats du serveur au client avec la commande SCP mais avant nous allons créer la même arborescence sur notre client.
une fois cela fait , nous pouvons lancer notre commande SCP suivante :

Il faut bien sur avoir les droit d’écrit dans le répertoire de destination.

Maintenant nous allons créer le fichier de configuration du client.

remote = l’adresse IP de notre serveur VPN et le deuxième rectangle le chemin vers nos certificat et clé.
On redémarre le service openVPN

Nous allons lancer le fichier de configuration avec la commande : openvpn client-linux

il a ajouté une route au client pour joindre le réseaux de notre tunnel et
La ligne « Initialization Sequence Completed » nous indique que tout s’est bien passé.

Liaison VPN avec le client en dehors de notre réseaux.

Comme sur le schéma de présentation notre client se trouve du coté WAN de notre pare-feu.
Nous devons changer quelques configuration sur nos fichier de conf précédent.
On va commencer par le fichier client :

Au lieu d’indiquer directement notre Serveur VPN , nous indiquons maintenant l’adresse IP WAN de notre pare-feu, toujours avec le port openvpn à savoir le 1194

Configuration de Pfsense (pare-feu).

Nous allons configurer Pfsense pour quand qu’il reçoit une demande notre client sur le port 1194 qu’il l’a redirige à notre serveur VPN.
Nous allons dans le menu Firewall/nat :

Ici mes règles sont déjà créés, vous n’aurez pas cela nativement il faudra les créer comme nous allons voire ici.

Remarque :Si l’interface Wan de votre PFSENSE est dans un réseaux privé il faut désactiver les options suivantes dans les paramètres WAN :

Configuration du serveur VPN.

Notre client aura bien accès au serveur VPN et pourra communiquer avec le vlan 10, Mais si on souhaite qu’il puisse communiquer avec tous nos vlan , il faut indiquer au serveur d’ajouter les routes vers ces réseaux :

les deux dernières lignes sont pour ajouter les routes.

Tout cela est bien beau , mais il reste un matériel à configurer, notre routeur Cisco pour qu’il accepte de router !!
Nous allons lui créer une nouvelle route pour rejoindre notre réseaux virtuel avec la commande suivante :
ip route 10.0.0.0 255.255.255.0 172.16.3.97
Nous avons finis notre configuration, nous allons tester tout cela !
Mais avant on aurait pas oublié une étapes? il faut dire à notre serveur vpn qu’il a la fonction routage pour gérer la nouvelle route de notre routeur CISCO :

Test.

Nous redémarrons le service openVPN sur notre client et serveur.
Puis nous initions la connexion des deux.
Nous allons voire dans les logs de notre client s’il a bien initié la connexion et ajouté les routes :

Il a bien ajouté les routes et initié la connexion.

Nous allons voire les logs du serveur aussi :

Nous voyons qu’il a bien établi la connexion avec notre  » client-linux  » et lui a envoyé ces nouvelle routes.

Nous lançons un ping d’un de nos sous réseaux avec le client :

Nous voyons que notre client adresser en 192.168.5.17 avec comme passerelle 192.168.5.252. Atteint bien grâce à notre tunnel VPN nos sous-réseaux