Virtual Private Network (VPN) par soi-même

1 Aperçu

Un réseau privé virtuel (VPN) est utilisé pour créer un champ privé de communications informatiques ou pour fournir une extension sécurisée d'un réseau privé à travers un réseau non sécurisé.
communications informatiques ou fournir une extension sécurisée d'un réseau privé à travers un réseau non sécurisé
réseau non sécurisé tel que l'Internet. Le VPN est largement utilisé pour la sécurité des réseaux. Le VPN peut être construit sur
IPSec ou Secure Socket Layer (SSL). Il s'agit de deux approches fondamentalement différentes pour
construire des VPN. Dans notre travail, nous nous sommes concentrés sur les VPN basés sur SSL qui sont souvent appelés
VPN SSL.
La conception et la mise en œuvre des VPN SSL illustrent un certain nombre de principes et de technologies de sécurité, y compris la cryptographie, l'intégrité, la sécurité des données et la sécurité des données.
de sécurité, notamment la cryptographie, l'intégrité, l'authentification, la gestion des clés, l'échange de clés et l'infrastructure à clé publique (ICP).
l'infrastructure à clé publique (ICP). Pour atteindre cet objectif, nous avons implémenté un VPN SSL simple pour le système d'exploitation Linux Ubuntu.
système d'exploitation Linux Ubuntu.

 

 

2 Configuration de l'environnement

Après avoir téléchargé les documents et les fichiers requis à partir de la page web officielle du laboratoire, nous avons fait 3
copies d'Ubuntu dans chacun des deux PCs sur lesquels nous avons travaillé. La première copie était le client (l'hôte)
serveur, tandis que la troisième était la passerelle, comme le montre la figure ci-dessous.
figure ci-dessous :
Ces 6 machines virtuelles ont travaillé sur 2 PC physiques pour les différentes parties du laboratoire.
Les captures d'écran suivantes montrent les adresses de l'hôte et du serveur sur une machine :
La machine serveur :

La machine hôte :

Pour l'environnement du laboratoire, nous avons utilisé la station de travail VMware sur les systèmes d'exploitation Ubuntu et Linux Mint.
donc, nous n'avons pas eu de problème d'UUID.
Les adresses IP des machines virtuelles ont été changées pour différentes parties du laboratoire en fonction des besoins.
les besoins.
Dans les étapes de configuration, nous avons ajouté une autre carte Ethernet à chacune des 6 machines virtuelles et nous avons fait en sorte que l'une d'entre elles soit NAT et l'autre NAT.
et avons fait en sorte que l'une d'entre elles soit NAT et l'autre (Host-Only) pour permettre la transmission IP et le routage entre les 2 sous-réseaux distants sur le réseau.
entre les deux sous-réseaux distants sur Internet, comme nous l'expliquerons plus tard.
Après avoir allumé l'hôte et le serveur de chaque côté, nous nous sommes assurés qu'ils sont connectés l'un à l'autre de la manière suivante
l'un à l'autre comme suit :

Enfin, l'openssl doit être activé dans toutes les machines pour pouvoir se connecter à travers un tunnel.
tunnel et nous avons pu constater que openssl est déjà activé dans les machines virtuelles comme suit
comme suit :

3 Créer un tunnel d'hôte à hôte en utilisant TUN/TAP

La technologie habilitante pour les VPN TLS/SSL est TUN/TAP, qui est maintenant largement implémentée dans les systèmes d'exploitation modernes.
largement implémentée dans les systèmes d'exploitation modernes. TUN et TAP sont des pilotes de noyau de réseau virtuel ;
Ils mettent en œuvre des périphériques réseau qui sont entièrement pris en charge par le logiciel. TAP (comme dans network tap)

simule un périphérique Ethernet et fonctionne avec des paquets de couche 2 tels que les trames Ethernet ; TUN
(comme dans network TUNnel) simule un périphérique de couche réseau et fonctionne avec des paquets de couche 3 tels que des paquets IP.
tels que les paquets IP. Avec TUN/TAP, nous pouvons créer des interfaces réseau virtuelles.
pour créer le tunnel d'un hôte à l'autre, comme le montre la figure ci-dessous :
Un programme en espace utilisateur est généralement attaché à l'interface réseau virtuelle TUN/TAP. Les paquets
envoyés par un système d'exploitation via une interface réseau TUN/TAP sont transmis au programme de l'espace utilisateur.
utilisateur. D'autre part, les paquets envoyés par le programme via une interface réseau TUN/TAP sont
injectés dans la pile réseau du système d'exploitation ; pour le système d'exploitation, il semble que les
paquets proviennent d'une source externe via l'interface réseau virtuelle.
Lorsqu'un programme est attaché à une interface TUN/TAP, les paquets IP que l'ordinateur envoie à cette interface sont injectés dans la pile réseau du système d'exploitation.
cette interface seront acheminés vers le programme ; d'autre part, les paquets IP que le programme envoie à l'interface seront acheminés vers le programme.
programme envoie à l'interface seront acheminés vers l'ordinateur, comme s'ils provenaient de l'extérieur via cette interface
cette interface réseau virtuelle. Le programme peut utiliser les appels système standard read() et write()
pour recevoir ou envoyer des paquets depuis ou vers l'interface virtuelle.
Dans ce laboratoire, nous avons utilisé le programme simpleton.c pour créer des tunnels, que nous avons téléchargé depuis le site web du laboratoire.
site web du laboratoire et nous avons pu le compiler en utilisant :
$ gcc -o simpletun simpletun.c
Et les résultats étaient :

Ensuite, pour continuer le processus de connexion de tunnel d'hôte à hôte, nous allumons les deux hôtes, leur attribuons des adresses IP comme requis, faisons fonctionner le système d'exploitation et le système d'exploitation.
adresses IP comme il se doit, faisons fonctionner simpletun sur les deux en tant que client (-c) sur le premier et
comme serveur (-s) dans le second, puis nous avons configuré les routes et nous avons pu voir ceci :

Ce qui montre que les deux hôtes sont maintenant connectés à travers le tunnel.
Et nous pouvons faire un ping de chacun d'eux vers l'autre :

4 Créer un tunnel hôte-voie d'accès

Après avoir réussi à configurer le tunnel sur les deux VMs dans une seule machine hôte, nous avons configuré
un tunnel similaire sur deux VMs sur deux machines hôtes différentes. Et pour que cette configuration
configuration, nous avons utilisé la redirection de port à cette fin, comme indiqué ci-dessous :

Ici, nous avions besoin de créer un tunnel entre un ordinateur et une passerelle, permettant à l'ordinateur de
d'accéder au réseau privé qui est connecté à la passerelle. Pour ce faire, nous avions besoin de deux adresses physiques ordinateurs. Sur un ordinateur, nous exécutons plusieurs VMs pour configurer la passerelle et le réseau privé.
et le réseau privé. Nous avons ensuite utilisé une VM dans l'autre ordinateur pour communiquer avec les hôtes
sur le réseau privé.
Après avoir configuré les deux machines, nous avons obtenu ce qui suit :
La connexion s'est établie avec succès :

La table de routage et la capacité de ping vers l'autre partie du tunnel :

Sur l'autre machine, nous avons :
La connexion établie :

Pinging de l'autre côté du réseau (à travers le tunnel)

Le terminal du tunnel capture le trafic passant par le tunnel :

 

5 Créer un tunnel Gateway-to-Gateway

Dans cette tâche, nous devions aller un peu plus loin pour établir un tunnel entre deux passerelles de
différents réseaux privés. Avec ce tunnel, n'importe quel hôte d'un réseau privé peut
communiquer avec les hôtes de l'autre réseau privé en utilisant le tunnel. La configuration d'un tel tunnel
tunnel de passerelle à passerelle est illustrée ci-dessous :
Après avoir créé les deux réseaux indiqués ci-dessus dans les deux machines physiques, nous avons créé le
tunnel entre les deux passerelles et nous avons pu obtenir une connectivité à travers le tunnel de chacune d'entre elles vers l'autre, comme indiqué ci-dessous: :.
chacune d'elles vers l'autre, comme illustré ci-dessous :
Pinging d'un côté du tunnel à l'autre :

Le tunnel capturant le trafic :

Les cartes de la passerelle :

La passerelle de l'autre côté, avec le terminal du tunnel capturant le trafic :

6 Créer un réseau privé virtuel (VPN)

Après avoir créé le tunnel de passerelle à passerelle ou le tunnel réseau. Ensuite, nous avons sécurisé ce
tunnel pour obtenir le VPN. Et pour sécuriser ce tunnel, nous devions atteindre deux objectifs ,
la confidentialité et l'intégrité. La confidentialité est obtenue en utilisant le cryptage, c'est-à-dire que le contenu
qui passe par le tunnel est crypté. Un vrai logiciel VPN supporte généralement un certain nombre de
différents algorithmes de cryptage. Mais pour notre laboratoire, nous avons seulement besoin de supporter l'algorithme de cryptage AES.
et nous avons utilisé le mode Cipher Block Chaining (CBC).
L'objectif d'intégrité est de s'assurer que personne ne peut modifier le trafic dans le tunnel ou lancer une attaque par relecture.
attaque par relecture. L'intégrité peut être obtenue en utilisant différentes méthodes. Dans ce laboratoire, nous avons seulement besoin de
supporter la méthode Message Authentication Code (MAC). L'algorithme de cryptage AES et
l'algorithme HMAC-SHA256 sont tous deux implémentés dans la bibliothèque OpenSSL. Et nous avons utilisé [1]
pour mettre en œuvre les exigences mentionnées ci-dessus. Pour cette tâche, nous avons supposé que la clé secrète
est déjà fournie. Pour le cryptage, le client et le serveur doivent également convenir d'un vecteur initial (IV).
vecteur initial (IV). Pour des raisons de sécurité, l'IV ne doit pas être codé en dur dans le code. Au contraire, l'IV doit
être généré aléatoirement pour chaque tunnel VPN.
Pour démontrer notre travail pour cette partie, nous aimerions montrer ce qui suit :
Tout d'abord, nous avons travaillé sur les fichiers d'échantillons open ssl du site web du laboratoire et obtenu les codes c++ du client et du serveur.
serveur en c++, puis nous les avons modifiés et compilés pour obtenir ce qui suit :

Comme il est montré ci-dessus, nous avons obtenu les exécutables cli (pour le client) et serv (pour le serveur). De plus, pour montrer
le contenu du fichier de certificat (server.crt), nous avons obtenu ce qui suit :

Les programmes client-serveur dans notre travail comprennent un simple échange de données sur le SSL et le tunnel (le VPN).
(le VPN) et il est montré ci-dessous :

Après avoir émis les programmes serveur et client sur les deux machines virtuelles, nous avons entré la clé partagée dans les deux machines pour obtenir le certificat de sécurité.
Après avoir lancé les programmes serveur et client sur les deux machines virtuelles, nous avons entré la clé partagée dans chacune d'entre elles pour obtenir les messages ci-dessus de chacune d'entre elles à l'autre et voici
une autre capture d'écran de clarification :

Enfin, les éléments suivants montrent le contenu du fichier de certificat côté client :

7 Authentification et échange de clés

Avant qu'un VPN ne soit établi, le client VPN doit authentifier le serveur VPN, en s'assurant
que le serveur n'est pas un serveur frauduleux. D'autre part, le serveur VPN doit authentifier le client (c'est-à-dire l'utilisateur).
client (c'est-à-dire l'utilisateur), en s'assurant que l'utilisateur a la permission de créer un tel tunnel VPN.
Une fois l'authentification effectuée, le client et le serveur conviennent d'une clé de session pour le tunnel VPN.
tunnel VPN. Cette clé de session n'est connue que du client et du serveur. Le processus de
Le processus d'obtention de cette clé de session est appelé échange de clés et peut être réalisé en suivant les
étapes suivantes.
Étape 1 : Authentification du serveur VPN Une façon typique d'authentifier le serveur est d'utiliser des certificats à clé publique.
publics. Le serveur VPN doit d'abord obtenir un certificat à clé publique d'une autorité de certification (CA), telle que VeriSign.
Autorité de Certification (CA), telle que Verisign. Lorsque le client se connecte au serveur VPN, le serveur utilise le certificat pour prouver son identité.
serveur utilisera le certificat pour prouver qu'il est le serveur prévu. Le protocole HTTPS du Web
utilise une méthode similaire pour authentifier les serveurs Web, garantissant que vous parlez à un serveur Web prévu et non à un faux.
prévu et non à un faux serveur. Notre MiniVPN a utilisé une telle méthode pour authentifier le serveur VPN. Nous avons
mis en œuvre un protocole d'authentification (tel que SSL) en utilisant les fonctions SSL d'OpenSSL pour établir directement une connexion SSL entre le client et le serveur, où la vérification des certificats est automatiquement effectuée par le serveur SSL.

 

pour établir directement une connexion SSL entre le client et le serveur, où la vérification des certificats est automatiquement effectuée par les fonctions SSL.
certificats est automatiquement effectuée par les fonctions SSL.

Étape 2 : Authentification du client VPN (c'est-à-dire de l'utilisateur) Il existe deux façons courantes d'authentifier l'utilisateur.
utilisateur. La première consiste à utiliser les certificats à clé publique. En d'autres termes, les utilisateurs doivent obtenir leurs propres certificats de clé publique.
publics. Lorsqu'ils essaient de créer un VPN avec le serveur, ils doivent envoyer leurs certificats au serveur.
au serveur, qui vérifiera s'ils ont les autorisations pour un tel VPN. Les fonctions SSL d'OpenSSL
d'OpenSSL supportent également cette option.
Étant donné que les utilisateurs ne disposent généralement pas de leurs certificats à clé publique, un moyen plus courant d'authentifier les utilisateurs est d'utiliser la méthode traditionnelle d'authentification.
d'authentifier les utilisateurs est d'utiliser l'approche traditionnelle du nom d'utilisateur et du mot de passe. En d'autres termes, après que le
client et le serveur ont établi une connexion TCP sécurisée entre eux, le serveur peut demander au client de saisir le nom d'utilisateur et le mot de passe.
peut demander au client de taper son nom d'utilisateur et son mot de passe.
d'autoriser l'utilisateur à continuer selon que le nom d'utilisateur et le mot de passe correspondent aux informations de la base de données des utilisateurs du serveur.
informations de la base de données des utilisateurs du serveur.

Étape 3 : Échange de clés. L'utilisation des fonctions SSL d'OpenSSL entraîne l'établissement automatique d'un canal sécurisé (par le serveur OpenSSL).
automatiquement établi (par les fonctions OpenSSL). Cependant, cette connexion TCP n'a pas été
utilisée pour notre tunnel, car notre tunnel VPN utilise UDP. Par conséquent, nous avons traité cette connexion TCP
comme le canal de contrôle entre le client et le serveur. Sur ce canal de contrôle,
le client et le serveur conviennent d'une clé de session pour le canal de données (c'est-à-dire le tunnel VPN).
Ils peuvent également utiliser le canal de contrôle pour d'autres fonctionnalités, comme la mise à jour de la clé de session,
l'échange du vecteur initial (IV), la fin du tunnel VPN, etc.

Étape 4 : Reconfiguration dynamique. Certaines commandes côté client ont été implémentées pour permettre au client de
pour permettre au client de faire ce qui suit :
- Changer la clé de session du côté client, et informer le serveur d'effectuer le même changement.
- Changer l'IV du côté client, et informer le serveur d'effectuer le même changement.
- Rompre le tunnel VPN actuel. Le serveur doit être informé afin de libérer les ressources correspondantes.
ressources correspondantes.
Nous avons essayé de réaliser ceci mais nous n'avons pas pu le faire à cause des limitations de temps et des examens.
8 Support de plusieurs tunnels VPN
Dans le monde réel, un serveur VPN supporte souvent plusieurs tunnels VPN. En d'autres termes, le serveur VPN
permet à plus d'un client de s'y connecter simultanément ; chaque client a son propre tunnel VPN avec le serveur, et la session se termine par un tunnel VPN.
avec le serveur, et les clés de session utilisées dans les différents tunnels doivent être différentes. Notre serveur VPN était capable de supporter plusieurs clients. Lorsqu'un paquet arrive au serveur VPN
à travers un tunnel VPN, le serveur doit déterminer de quel tunnel VPN le paquet provient.
du paquet. Sans cette information, le serveur ne peut pas savoir quelle clé de décryptage (et IV) doit être utilisée pour décrypter le paquet.
être utilisée pour décrypter le paquet ; l'utilisation d'une mauvaise clé va entraîner l'abandon du paquet,
car le HMAC ne correspondra pas.

La première machine avec plusieurs clients exécutant le client SSL :

t est montré ici qu'ils ont obtenu les réponses du côté serveur.
Le côté serveur avec des connexions multiples à différents clients montrés ci-dessous :
Il est montré ici que ce serveur était capable de communiquer avec plusieurs clients simultanément.