L’objectif de ce TP est de mettre en place les différents vlans et tester le routage statique: Télécharger ici
Matériels indispensables
Installations des paquet sur le serveur VPN et sur le client Debian
"apt-get install openssl"
"apt-get install openvpn"
Construction d’un tunnel
Afin de faire de voir comment une connexion VPN est initiée, nous allons tout d’abord utiliser les commandes suivantes au niveau du serveur et du client.
Ouvrir le terminal en tant que root et taper les commandes suivantes:
Au niveau du serveur: openvpn –dev tun0 –verb 5 –ifconfig 10.0.1.1 10.0.1.2 #10.0.1.1 étant l’adresse IP de l’interface virtuelle du serveur et 10.0.1.2 l’interface virtuelle du client.
Au niveau du client: openvpn –dev tun0 –verb 5 –ifconfig 10.0.1.2 10.0.1.1 –remote 172.16.2.3 # 172.16.2.3 étant l’adresse IP du serveur VPN.
Test
Nous allons par la suite ouvrir un deuxième terminal depuis le client et essayer de faire un ping de l’interface virtuelle du serveur VPN depuis l’interface eth0 et capturer par la même occasion la trame:
NB: les machines sont dans le VLAN 10
Nous ferons de même au niveau de l’interface tun0
Création de certificat avec Openssl
pour crée des certificats, nous allons commencer par construire un tunnel chiffré avec des certificats. Pour cela nous allons mettre en place les certificats de l’autorité de certification du client et du serveur.
Nous commençons par créer les répertoires suivants:
Ex: mkdir -p /apps/esy-rsa
par la suite nous allons copier le répertoire /usr/share/easy-rsa dans le dossier /apps/easy-rsa, à l’aide de la commande suivante: cp -R /usr/share/easy-rsa /apps/easy-rsa
Nous allons modifier les variables suivantes dans le fichier /apps/easy(rsa/vars
Par la suite, nous exportons les variables créées en appliquant ces valeurs à l’aide de la commande: « source vars » ( commande à taper en étant dans le répertoire /apps/easy-rsa )
Créer 3 groupes de certificat/clés privées: pour l’autorité, le serveur et le client ( chaque nouveau client devra en avoir un).
Création du certificat de l’autorité
Créer un certificat d’autorité de certification et avec sa clé à l’aide du script « ./build-ca« . Le certificat sera enregistré dans un fichier nommé « ca.crt » et la clé dans un fichier nommé « ca.key« , tous deux dans le dossier /apps/easy-rsa.
Dans le répertoire /apps/easy-rsa nous lançons le script « ./build-ca », c’est ce certificat qui validera tous les autres excepté celui du serveur. nous répondrons aux questions pour lesquelles nous n’avons pas donné les valeurs par défauts.
Générer des certificats
Comme nous avons vu plus haut, le serveur aura son propre certificat, signé par la CA que nous venons de créer. pour cela, nous allons utiliser le script « ./build-key-server ». le certificat sera enregistré dans le fichier nommé « server.crt » et le la clé dans un fichier nommé « server.key« , tous deux dans le dossier /apps/easy-rsa/:
Exécuté le script « ./build-key-server srv-vpn » (srv-vpn étant le nom du serveur VPN ).
NB: lancer à chaque fois le script « source vars » pour charger le fichier où se trouve les scripts.
Pendant la configuration laisser les valeurs par défauts aux paramètres qui nous sont demandés ( paramètres qui ont été modifiés au départ dans le fichier /apps/easy-rsa/vars )
Pour générer le certificat du client, nous utiliserons le script « build-key« . Le certificat sera enregistré dans un fichier du nom de votre choix, en .crt et la clé dans un fichier du nom de votre choix en .key, tous deux dans le dossier /apps/easy-rsa/ . Le certificat et la clé doivent être uniques pour chaque vient.
Exécutez le script « ./build-key Deb-client »
Création de la clé de session de DIFFIE-HELLMAN
Diffie-Hellman: est un protocole de cryptographie utilisé dans les échanges de clés. Cette clé sera utilisée par le serveur et le client pour communiquer en utilisant la cryptographie symétrique. Nous allons utiliser le script « build-db » prévu à cet effet, qui va générer une clé de chiffrement de 2048 bits dans le fichier « dh2048.pem » qui se trouve dans le dossier /apps/easy-rsa.
Exécutez le script ./bulid-db
Récapitulatif des fichiers crées
Configuration du serveur VPN
Afin de démarrer une instance de serveur VPN, le démon Openvpn vient chercher le répertoire /etc/openvpn, un fichier nommé « server.conf » qui lui permettra de savoir avec quelles options lancer le tunnel.
bous allons commencer par créer ce fichier dans le répertoire « /apps/openvpn/conffiles« .
Après la création nous allons configurer le fichier comme suit:
proto udp
dev tun
ca /apps/openvpn/keys/ca.crt
cert /apps/openvpn/keys/srv-vpn.crt
key /apps/openvpn/keyx/srv-vpn.key
dh /apps/openvpn/dh2048.pem
server 192.168.0.0 255.255.255.0
client-to-client #permet aux clients de se voir entre eux
#règle permettant une persistance de connexion et du cryptage et déterminant la durée de cette persistance
keepalive 10 120
pesrsist-key
persist-tun
# tls-auth ta.key 0 # à décommenter si on souhate n’autoriser les demandes de connexions qu’au possesseur d’une clé de cryptage spécifique. ceci augmente la sécurité et prévient les attaques Dos
cipher AES-128-CBC # algorithme de cryptage identique sur le client
# règles et lieu d’écriture des logs
status openvpn-status.log
log /apps/openvpn/log/openvpn.log
log /apps/openvpn/log/openvpn.log
verb # mode verbeux pour l'écriture des logs
Afin de tester la bonne configuration de ce fichier nous allons ouvrir 2 terminaux et lancer les commandes suivantes:
"openvpn server.conf"
« tail -f /apps/openvpn/openvpn.log » pour voir les logs, nous devons avoir une « Initialization Sequence Completed » dans les logs.
Au niveau du client, créer les mêmes répertoires que sur le serveur du moins celui-ci /apps/openvpn/keys
Nous allons transférer les certificats et les clés privées clients générés au niveau du serveur dans le répertoire /apps/openvpn/keys du client ( Si le client est une machine Linux). Pour cela on va utiliser la commande « scp CheminFichieràEnvoyer utilisateur@IPClient:/ » pour le copier dans le répertoire personnel ensuite dans le bon répertoire.
Ensuite dans le répertoire /apps/openvpn/keys
Dans le répertoire « /etc/openvpn« , nous allons créer le fichier « client.conf«
"touch client.conf"
Après la création du fichier le fichier comme suit:
Nous allons par la suite copier ce fichier dans le répertoire /apps/openvpn/conffiles/
Test
Nous allons redémarrer notre notre serveur avec la commande « openvpn server.conf »
Sur le client lancer la commande suivante: « openvpn client.conf« , nous observons bine « Initialization sequence Completed«
Si nous lançons un ping de l’interface virtuelle du serveur, nous pouvons constater que le client communique bien avec le serveur.
Préparation du serveur VPN
Nous allons placer notre client dans le Vlan du Greta qui est le vlan 70 (considéré comme le WAN)
afin que le client se trouvant dans le WAN puisse avoir accès au réseau interne, le serveur doit posséder la route lui indiquant de rédiriger les requêtes vers le réseau concerné. Nous ajoutons les routes (à la fin du fichier) vers notre réseau de destination de la manière suivante dans le fichier /apps/openvpn/conffiles/server.conf:
push "route 172.16.2.0 255.255.255.0"
push "route 172.19.0.0 255.255.255.128"
Liaison VPN avec le client extérieur à notre réseau
Dans le fichier de configuration du client qui se trouve coté WAN de notre pare-feu, nous allons modifier la configuration comme suit:
Dans ce fichier nous indiquons l’adresse IP du pare-feu côté WAN avec le port associé
Nating et filtrage
Afin d’activer le routage sur notre serveur VPN, nous éditons le fichier « /etc/sysctl.conf » et nous décommettons la ligne suivante: « net.ipv4.ip_forward=1«
Créer une règle au niveau du pare-feu, afin que le client soit redirigé vers notre VPN lorsqu’il fait une demande sur le port « 1194« .
Pour cela aller dans le menu Pare-feu/Nat et remplir les champs comme suit:
NB: ne pas oublier de décocher les cases ci-dessous au niveau du pare-feu dans le menu INTERFACE >WAN. Car de base l’interface WAN bloque le trafic des adresses IP qui sont réservés au réseaux privées et les boucles locales.
Il faut renseigner au niveau du routeur, le chemin pour joindre notre réseau virtuel avec la commande suivante:
"ip route 192.168.0.0 255.255.255.0 172.16.2.3"
Test
Nous redémarrons le service openvpn sur le serveur et le client, puis nous initions une connexion entre les 2 à l’aide des commandes: « openvpn server.conf« côté serveur et « openvpn client.conf » côté client.
Nous pouvons voir au niveau du serveur que pour aller sur les réseaux Data et WiFi, le client se trouvant dans le WAN va emprunter le réseau virtuel 192.168.0.0 via le 192.168.0.5.
Si nous lançons un ping depuis notre client se trouvant dans le réseau du Greta vers notre réseau LAN, on peut apercevoir qu’il communique bien avec notre réseau DATA
Un peu d’histoire
Aux origines de TCP/IP, étant donné que les réseaux étaient très peu étendus, que le nombre d’ordinateurs connectés à un même réseau était faible, les administrateurs réseau créaient des fichiers appelés tables de conversion manuelle. Ces tables de conversion manuelle étaient des fichiers séquentiels ( c’est-à-dire des fichiers accessibles les uns après les autres), généralement nommés hosts ou hosts.txt, associant sur chaque ligne l’adresse de la machine et le nom littéral associé, appelé nom d’hôte.
Introduction au DNS
Le problème avec le système précédent est qu’il nécessitait néanmoins la mise à jour manuelle des tables de tous les ordinateurs en cas d’ajout ou de modification d’un nom de machine. Ainsi, avec l’explosion de la taille des réseaux, et de leur interconnexion, il a fallu mettre en place un système de gestion des noms hiérarchisés et plus facilement administrable. Le système nommé Domain Name System (DNS), traduisez Système de nom de domaine, a été mis au point en novembre 1983 par Paul Mockapetris, puis révisé en 1987 dans les RFCs 1034 et 1035. Le DNS a fait l’objet depuis de nombreuses RFCs.
L’architecture de réseau TCP/IP sur lequel est basé internet et la plupart des réseaux locaux actuels, utilisent des adresses IP numériques du type 192.168.0.1. mais pour faciliter la lecture de ces adresses par l’homme, un système permet de transformer ces adresses en adresses plus lisibles comme www.google.com.
Pour effectuer cette opération, il est nécessaire d’utiliser un serveur DNS. Il fera donc la correspondance entre les adresses IP et les noms de domaines. Un serveur DNS s’occupe en général d’un domaine limité et s’occupe de transmettre les questions à d’autres serveurs s’il ne connait pas la réponse.
Les serveurs de noms
Les machines appelées serveurs de nom de domaine permettent d’établir la correspondance entre le nom de domaine et l’adresse IP des machines d’un réseau. Chaque domaine possède un serveur de noms de domaines, appelé « serveur de noms primaire » (primary domain name server), ainsi qu’un serveur de noms secondaire (secondary domaine nameserver), permettant de prendre le relais du serveur de noms primaire en cas d’indisponibilité.
Chaque serveur de nom est déclaré dans un serveur de nom de domaine de niveau immédiatement supérieur, ce qui permet implicitement une délégation d’autorité sur les domaines. Les serveurs correspondant aux domaines de plus haut niveau (TLD) sont appelés « serveurs de noms racine ». Il en existe treize, répartis sur la planète, possédant les noms « a.root-servers.net » à « m.root-servers.net ».
Un serveur de noms définit une zone, c’est-à-dire un ensemble de domaines sur lequel le serveur a autorité. Le système de noms de domaine est transparent pour l’utilisateur, néanmoins il ne faut pas oublier les points suivants :
Résolution de noms de domaine
Le mécanisme consistant à trouver l’adresse IP correspondant au nom d’un hôte est appelé « résolution de nom de domaine ». L’application permettant de réaliser cette opération (généralement intégrée au système d’exploitation) est appelée « résolveur »
Lorsqu’un utilisateur souhaite se connecter à un hôte connu par son nom de domaine (par exemple « www.google.fr »), celui-ci va interroger un serveur de noms défini dans sa configuration réseau. Chaque machine connectée au réseau possède en effet dans sa configuration les adresses IP de deux serveurs de noms de son fournisseur d’accès.
Une requête est ainsi envoyée au premier serveur de noms (appelé « serveur de nom primaire »). Si celui-ci possède l’enregistrement dans son cache, il l’envoie à l’application, dans le cas contraire il interroge un serveur racine (dans notre cas un serveur racine correspondant au TLD « .fr »). Le serveur de nom racine renvoie une liste de serveurs de noms faisant autorité sur le domaine (dans le cas présent les adresses IP des serveurs de noms primaire et secondaire de google.fr).
Le serveur de noms primaire faisant autorité sur le domaine va alors être interrogé et retourner l’enregistrement correspondant à l’hôte sur le domaine (dans notre cas www).
Pourquoi installer un serveur DNS
Pour au moins deux raisons :
Lorsqu’une demande de résolution de nom est demandée, le système commence par regarder le fichier « /etc/host.conf »
La première ligne du fichier indique qu’il faut commencer la recherche en regardant la table hosts locale et ensuite il faut interroger le serveur DNS.
La table hosts locale est enregistrée dans le fichier « /etc/hosts ». Il contient une table de correspondance entre les adresse IP et des noms.
Si le résultat n’est pas trouvé dans la table hosts, le système recherche le serveur DNS indiqué dans le fichier « /etc/resolv.conf »
BIND (Berkley Internet Naming Daemon): c’est le programme utilisé pour faire la maintenance d’un serveur DNS sous linux.
Dans ce TP, nous allons configurer un serveur pour qu’il agisse en tant que serveur DNS primaire/Master (c’est un serveur principal qui fonctionne tout le temps)
Avant l’installation du serveur DNS, nous allons tout d’abord faire une mise à jour de la source list, au cas où il y’ aurai eu des modifications depuis sa dernière utilisation. Pour cela nous allons taper la commande: « apt-get update».
Pour l’installer il faut ouvrir son terminal en mode administrateur et taper la commande suivante : « apt-get install bind9 »
Une fois installer vérifier avec les commandes :
« ps –ax » ; qui permet de voir la liste des processus en cours d’exécution.
« netstat –atn » ; qui permet de voir si le port du DNS est ouvert.
Ce serveur DNS peut aussi être configuré en tant que DNS cache, toutefois pour des raisons de sécurité il n’est pas conseillé de le faire. Le rôle d’un serveur DNS cache est d’envoyer les requêtes aux autres serveurs DNS et de garder en cache les réponses. Ainsi la prochaine fois que la requête sera faite, la réponse sera récupérée directement depuis le cache. Cache qui est mise à jour de façon régulière.
Les fichiers suivants se trouvent dans les répertoires « /etc »
Fichier /etc/network/interfaces
L’éditer et le configurer en IP statique, pour éviter le changement d’adresse lorsqu’il est configuré dynamiquement. Ensuite le redémarrer afin qu’il prennent les changement en compte avec la commande : « /etc/init.d/networking restart ». Ce fichier décrit la configuration des interfaces réseau disponibles sur mon système d’exploitation.
Il sera configuré comme suit :
Fichier /etc/host.conf
Lorsqu’une demande de résolution de nom est demandée (c’est-à-dire lorsque l’utilisateur tape par exemple l’adresse www.google.fr), le système commence par regarder le fichier « /etc/host.conf »
La première ligne du fichier indique qu’il faut commencer la recherche en regardant la table hosts locale et ensuite il faut interroger le serveur DNS Bind.
Fichier /etc/hosts
La table hosts locale est enregistrée dans le fichier « /etc/hosts ». Il contient une table de correspondance entre les adresse IP et des noms.
La première ligne est obligatoire pour que le système fonctionne bien même quand le réseau est désactivé. L’adresse 127.0.0.1 est toujours associé au nom localhost.
La ligne suivante peut être ajoutée manuellement pour faire la correspondance entre les adresses IP et des noms. C’est ce qui est fait en l’absence du serveur DNS
Fichier « /etc/resolv.conf
À défaut de connaitre l’IP de la machine via le fichier de nom « /etc/hosts », le resolver DNS utilise le ou les serveurs DNS mentionnés dans le fichier /etc/resolv.conf pour effectuer ses requêtes
Toutes les configurations DNS sont stockées dans le répertoire /etc/bind.
Fichier /etc/bind/named.conf
C’est le fichier de configuration principale qui contient la liste des zones ou domaine que le serveur DNS doit prendre en charge.
Fichier /etc/bind/named.conf.options
L’option « forwarders » permet de rediriger les requêtes qui ne sont pas résolues par notre serveur DNS local vers un autre serveur DNS distant, celui de notre FAI par exemple. Cela permet d’utiliser le cache d’un serveur déjà existant et donc d’obtenir des temps d’accès plus rapides. Si la requête DNS n’est pas résolue par le serveur DNS distant, alors la requête sera envoyée aux autres serveur DNS racine.
L’option « version none » permet de dissimuler la version de Bind. Car une personne malveillante peut vouloir récupérer la version de notre Bind afin de mener une attaque contre ce dernier s’il n’est pas à jour.
Si vous mettez en place votre DNS dans un environnement où il existe un proxy, désactiver les options: dnssec-validation no; et dnssec-enable no; afin de contourner le proxy.
Après ces modifications redémarrer le service avec la commande : « service bind9 restart
Fichier /etc/bind/named.conf.local
Ce fichier contient la configuration locale du serveur DNS, on y déclare les zones associées au domaine. On peut configurer autant de zones si nécessaire. Y sont indiqués les différents fichiers qui seront configurés plus bas: Le fichier /etc/bind/db.pawoed.org net et le fichier /etc/bind/db.pawoed.org.rev
Redémarrer le service et taper la commande « named-conf » pour vérifier s’il n’y a pas d’erreur dans le fichier de configuration.
Fichier /etc/bind/db.pawoed.org
Pour configurer ce fichier, le copier à partir du fichier local et le modifier, à l’aide de la commande : « cp /etc/bind/db.local /etc/bind/db.pawoed.org »
Après la configuration redémarrer le service avec la commande « service bind9 restart »
Fichier /etc/bind/db.rev
C’est le fichier où se trouve la configuration de la zone inverse. Pour le configurer, il faut le copier à partir du fichier de configuration de la zone inverse locale, avec la commande : « cp /etc/bind/db.127 /etc/bind/db.rev », ensuite l’éditer et le configurer comme suit :
Les commandes utiles
La commande ci-dessous vérifie le bon fonctionnement du service.
« named-checkconf –z »
Les commandes ci-dessous permettent de vérifier la validité des fichiers de zone :
« named-checkzone pawoed.org /etc/bind/db.pawoed.org»
La commande « nslookup » permet de vérifier la résolution de nom DNS. « nslookup dns.pawoed.org » j’ai bien la réponse de mon serveur qui me dit le nom de domaine « dns.pawoed.org » a bien l’adresse IP ‘192.168.0.12’.
La commande « host » permet de tester la résolution du nom et la résolution inverse.
La commande « dig » permet également de tester la résolution du nom et la résolution inverse, mais surtout d’interroger directement le serveur bind9 et obtenir de nombreuses autres informations. Le paramètre–x est obligatoire pour obtenir une réponse « ANSWER SECTION »
« dig dns.pawoed.org »
« dig –x 192.168.0.12 »
Si je fais : ping dns, le domaine pawoed.org, sera ajouté avant d’effectuer la demande de résolution du nom (la recherche du nom, portera donc sur dns.pawoed.org).
Configurer des fichiers suivants comme précédemment sur le serveur maitre :
Dans le fichier /etc/bind/named.conf.local du serveur primaire, renseigner l’adresse IP du serveur esclave comme ci-dessous :
