Etude155222555 PDF

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA
République Démocratique du Congo

Province du Haut-Katanga
Lubumbashi
www.esisalama.org
Étude d’une mise en place d’une solution de

déploiement d’un réseau VPN IPSec dynamique point-
to-multipoint
Travail présenté et défendu en vue de l’obtention

vue de l’obtention du grade d’ingénieur en
administration des systèmes et réseaux
informatiques
Par KASONGO SWANA Laure
Directeur : Bertin MPOLOMBWE
Co-Directeur : Daril SHINGALETA
Option : G3 Administration systèmes et réseaux
Octobre 2017
I
EPIGRAPHE
« L’intégrité est une composante essentielle de la sécurité. Et pas

seulement en informatique »
Didier Hallépée
II
DEDICACE
A notre chère mère ILUNGA TSHIKWAKWA ;
A notre cher Oncle ILUNGA KANZA ;
A notre chère Tante Ernestine KAYEYE ;
A nos très chers cousins Laurent KAVWELE, Alain, Pathy, Freddy SAMBA,
Emmanuel KASONGO, Joel KAYEYE, Daniel SWANA et cousines Gloria MUKUMBI,
Lydie KAYINDA, Jiselle MANYINDA, Naomie NSEWU pour leurs amours et leurs
attentions combien louables témoignés en notre faveur pour la réussite notre parcours
académique.
III
REMERCIEMENTS
Le cap que nous franchissons aujourd’hui n’est certainement pas le fruit du hasard
ni moins encore de nos propres efforts mais plutôt le résultat d’une longue lutte aux côtés
de ces personnes aimables et responsables, qui de toutes les manières imaginables nous
ont prêté main forte et encouragés.
Nous commençons premièrement par remercier respectivement notre directeur

Mr. Bertin POLOMBWE et notre co-directeur Mr. Darryl SHINGALETA, pour leurs
remarques constructives, leur disponibilité ainsi que leur patience.
Nos remerciements les plus sincères s’adressent également aux autorités

académiques de l’Ecole Supérieur d’Informatique Salama, premièrement au Directeur
Générale monsieur Jacquie MPUNGU et au Secrétaire académique monsieur Patrick
KASONGA, sans oublier notre coordonnateur Mr. Robert et à notre secrétaire de filière
Mr. Jonathan pour leur encadrement et soutient qu’ils nous ont offert.
Nos remercions également notre grande famille, notre mère pour son amour, nos
cousins : Fiston, Huguette KAYIND, Patricia MPEMBA, Jeampy MUTUNGA, Denis
MPIANA, Andy KAJAM, Glody LUTSHA, Dan TSHILEMEBE pour leur amour et
soutien indéfectible.
Mes éloges vont également à nos chères et sœurs : Gloria BANDA, Lucie
NAMUTELA, Urcel SWANA, Naomie et ma tendre jumelle Laurianne MPEMBA pour
leurs encouragements.
Nous disons aussi merci à nos amis, frères et sœurs en Christ, Marc, Guylith,
Noëlla, Rodrigue, Elie, Emmanuel, Grand Papy, Papa Lucien pour leurs contributions
spirituelles dans la réalisation de ce travail.
Le dernier merci ira à nos chères collègues de promotions : Jonathan NKUNGA,

Jonathan KABWE, Marcel KASANDA, Erick KISIMBA, Ruddy MULONGA, Daviane
KYUNGU, Joel MUKONDA, Jordi KASONGO.
A toutes les personnes que nous n’avons pas citées, sentez-vous également
remercier.
Laure KASONGO SWANA

IV
LISTE DES FIGURES
Figure 1.1 VPN d'accès .................................................................................................... 8

Figure 1.2 Intranet VPN ................................................................................................... 8
Figure 1.3 Extranet VPN .................................................................................................. 9
Figure 1.4 Format d'une trame PPP .............................................................................. 10
Figure 1.5 Protocole AH avec ses algorithmes .............................................................. 12
Figure 1.6 Protocole ESP avec ses algorithmes............................................................. 12
Figure 1.7 Diagramme de flux d'encapsulation avec le protocole GRE ........................ 13
Figure1.8 VPN GRE over IPSec ..................................................................................... 14
Figure 1.9 Architecture d'un VPN/MPLS ....................................................................... 15
Figure 1.10 Diagramme de classe du fonctionnement d'un tunnel VPN IPSec.............. 16
Figure 1.11 VPN Site-to-site ........................................................................................... 16
Figure 1.12 Architecture d'un réseau VPN en étoile ...................................................... 17
Figure 1.13 Architecture d'un réseau VPN maillé complet ............................................ 18
Figure 1.14 Exemple d'un VPN site-to-site .................................................................... 19
Figure 1.15 Configuration du tunnel VPN sur R1 .......................................................... 20
Figure 1.16 Configuration du tunnel sur R2 .................................................................. 21
Figure 1.17 Diagramme SysML des exigences fonctionnelles et techniques du futur
système ............................................................................................................................ 24
Figure 2.1 Niveau d'abstraction appliqué à la conception ............................................ 26
Figure 2.3 Enregistrement du Spoke sur le Hub ............................................................ 30
Figure 2.4 Paquets de communication entre Hub et Spoke ............................................ 31
Figure 2.5 Recherche récursive dans la table de routage .............................................. 40
Figure 2.6 Mémoire cache du CEF ................................................................................ 41
Figure 2.7 Fonctionnement de la phase 1 DMVPN....................................................... 33
Figure 2.8 Fonctionnement de la phase 2 DMVPN........................................................ 34
Figure 2.9 Fonctionnement de la phase 3 DMVPN........................................................ 36
Figure 2.11 Diagramme en batôn de comparaison des phases 1,2 et 3 ......................... 38
Figure 2.12 Diagramme radar de comparaison entre les phases 1, 2 et 3 .................... 38
Figure 3.1 Configuration des interfaces physiques de R1 .............................................. 50
Figure 3.2 Configuration des interfaces de R2............................................................... 50
Figure 3.5 Configuration des interfaces de loopback du Hub ....................................... 51
Figure 3.6 Configuration du VPCS ............................................................................... 52
Figure 3.7 Configuration du tunnel sur le Hub .............................................................. 53
Figure 3.8 Configuration du tunnel sur le Spoke_1 ....................................................... 54
V
Figure 3.9 Configuration du protocole routage EIGRP................................................. 55

Figure 3.10 Annonce des routes ..................................................................................... 56
Figure 3.11 Vérification des tunnels sur le Hub ............................................................. 57
Figure 3.12 Tunnel des tunnels sur le Spoke_3 .............................................................. 57
Figure 3.13 Test de connectivité ..................................................................................... 58
Figure 3.15 Tunnel dynamique entre Spoke_2 et Spoke_3 ............................................. 58
Figure 3.16 Tunnel dynamique entre Spoke_3 et Spoke_2 ............................................. 58
Figure 3.17 Vérification des sauts empruntés par un trafic ........................................... 59
Figure 3.18 Agrégation des routes en une route par défaut ........................................... 59
Figure 3.19 Table de routage de Spoke_1 après agrégation des routes ........................ 60
Figure 3.20 Configuration du protocole ISAKMP ......................................................... 61
Figure 3.21 Test de connectivité ..................................................................................... 62
Figure 3.22 Etat des tunnels IPSec ................................................................................. 62
VI
LISTE DES TABLEAUX
Tableau 1.1 Définition des exigences du futur système .................................................. 23

Tableau 2.1 Composant de la solution ........................................................................... 28
Tableau 2.2 Comparaison des trois solutions ................................................................ 37
Tableau 3.1 adressage de la topologie implémentée ...................................................... 46
Tableau 3.2 Procédure configuration du routeur Hub ................................................... 52
Tableau 3.3 Procédure de configuration d'un Spoke ..................................................... 53
Tableau 3.4 Procédure de configuration du protocole de routage EIGRP .................... 55
Tableau 3.5 Evaluation des besoins ............................................................................... 62
VII
LISTE DES ACRONYMES
AH Authentication Header
AES Advanced Encryption Standard
ARP Address Resolution Protocol
CEF Cisco Express Forward
DES Data Encryption Standard
DHCP Dynamic Host Control Protocol
DMVPN Dynamic Mutlipoint Virtual Private Network
EIGRP Enhanced Interior Gateway Routing Protocol
ESP Encryption Service Payload
GNS3 Graphic Network Simulator 3
GRE Generic routing protocol
IOS Internetworking Operating System
IP Internet Protocol
IPSEC Internet Protocol Security
IPX Inter-network Package eXchange
ISAKMP Internet Security Association Key
L2F Layer 2 Forwarding
L2TP Layer 2 Tunnel Protocol
MD5 Message Digest 5
MPLS Multi Protocol Label Switching
NAT Network Address Translation
NBMA Non Broadcast Multi Access
NHC Next-Hop Client
NHRP Next-Hop Resolution Protocol
NHS Next-Hop Server

VIII
OSPF Open Shortest Path First
PPP Point to Ponit Protocol
PPTP Point to Point Tunneling Protocol
QOS Quality Of Service
RFC Request For Comment
RIP Routing Interior Protocol
VPCS Virtual Private Computer Similator
VPN Virtual Prtivate Network
WAN Wide Area Network
3DES 3 Data Encryption Standard

IX
TABLE DES MATIERES
EPIGRAPHE ..................................................................................................................... I
DEDICACE ..................................................................................................................... II
REMERCIEMENTS ....................................................................................................... III
LISTE DES FIGURES ................................................................................................... IV
LISTE DES TABLEAUX .............................................................................................. VI
LISTE DES ACRONYMES ..........................................................................................VII
TABLES DES MATIERES ............................................................................................ IX
AVANT-PROPOS .......................................................................................................... XI
CHAPITRE 0 : INTRODUCTION GENERALE ............................................................ 1
0.1. Problématique .................................................................................................. 1
0.2. Hypothèse .......................................................................................................... 2
0.3. Choix et intérêt du sujet .................................................................................. 2
0.4. L’approche méthodologique ........................................................................... 3
0.5. Etat de l’art ....................................................................................................... 4
0.6. Délimitation du travail ..................................................................................... 4
0.7. Subdivision du travail ...................................................................................... 5
0.8. Outils logiciels et équipements utilisés ........................................................... 5
CHAPITRE 1 : ANALYSE DE L’EXISTANT ET SPECIFICATION DU FUTUR
SYSTEME ........................................................................................................................ 6
1.1. Présentation des VPN ...................................................................................... 6
1.2. Présentation et critique sur l’existant .......................................................... 15
1.3. Spécifications des besoins .............................................................................. 22
1.3 Conclusion partielle ....................................................................................... 25
CHAPITRE 2 : CONCEPTION DU SYSTEME ........................................................... 26
2.1. Introduction ........................................................................................................ 26
2.2. La méthodologie Top down design ................................................................... 26
2.3. Conception générale ........................................................................................... 26
2.4. Conception détaillée ........................................................................................... 27
2.5. Conception physique ...................................................................................... 41
2.5. Conclusion partielle ....................................................................................... 44
CHAPITRE 3 : IMPLEMENTATION DU SYSTEME ................................................. 45
3.1. Introduction .................................................................................................... 45
X
3.2. Simulation de la solution .................................................................................. 45

3.3. Mise en place de la simulation de la solution ................................................... 46
3.4 Planification et procédure .................................................................................. 49
3.5 Conclusion partielle ............................................................................................ 62
CONCLUSION GENERALE......................................................................................... 64
XI
AVANT-PROPOS
L’Ecole Supérieure d’Informatique Salama régie par le programme national des

institutions supérieures techniques, prévoit des défenses des travaux ou projets à la fin
des cursus académiques des ingénieurs techniciens en informatique, c’est dans cet ordre
d’idée que s’inscrit ce travail de fin d’études en administration systèmes et réseaux.
Toute entreprise, petite ou grande soit-elle, est appelée toujours à grandir et à

étendre son influence économique dans son milieu de travail en multipliant des sites
distants tout en assurant une connectivité sécurisée entre ces derniers. De nos jours, la
sécurité la moins couteuse pour des liaisons entres sites est assuré par des réseaux privés
virtuels via des infrastructures publiques.
De même lors de la mise en place d’un réseau privé virtuel, penser à

l’évolutivité ainsi qu’à la facilité de la gestion de ce dernier est d’une importance capitale
pour éviter bon nombre de problèmes tel que certaines lenteurs dans la transmission du
trafic sur le réseau.
Dans le présent travail, nous proposons une solution de déploiement d’un

réseau VPN IPSec dynamique en partant des spécifications fonctionnelles du futur
système, l’analyse de l’existant et la présentation des besoins, la conception générale et
l’implémentation du système qui résulte d’une étude minutieuse de diverses solutions
existantes.
Une bonne appréhension de ce travail exige le parcours total de tous les chapitres
étant donné que la fin ou la sortie de chaque chapitre constitue une entrée du prochain
chapitre, chaque cause placée dans le travail produit un effet dans le système.
1
CHAPITRE 0 : INTRODUCTION GENERALE
0.1. Problématique
A l’heure actuelle, les besoins en matière de sécurité, dans l’interconnexion des

sites distants d’une entreprise, sont grandissants, et la tendance n’est certainement pas à
la baisse.
Le réseau informatique étant en pleine croissance, toutes les entreprises, grandes
ou petites soient elles, cherchent à faire étendre leur pouvoir commerciale en multipliant
des succursales partout elles peuvent le faire. Pour relier ces différents sites distants, la
solution la plus économique de nos jours, est de passer par un réseau public qui peut être
Internet ou une boucle radio d’un provider via à un ensemble des tunnels sécurisé entre
les sites distants.
Les tunnels IPSec1 étant des réseaux point à point, la manière la plus facile pour
les faire évolués est de l’organiser en étoile là où nous avons le routeur du siège centrale
qui est le point central du réseau, tel un point d’accès, auquel se connecte les routeurs des
sites distants, IPSec ne supportant pas le cryptage de trafic de type multicast il est souvent
utilisé avec le protocole GRE2 qui est capable de transporter le trafic de type multicast
comme les mises à jours d’une table de routage.
En mettant en place un tel réseau, il se dégage quelques limites tels que :
 Il est très difficile voire même impossible d’installer et de gérer des
réseaux maillé complet ou partiel. Les réseaux maillet complet ou partiel
sont souvent souhaitable parce qu’il peut il y avoir des économies de coût
si le trafic entre succursale peut se faire au lieu de passer toujours par le
routeur du siège central qui est très souvent le routeur central du réseau.
 Le routeur central étant le point focal du réseau, il doit être configuré avec
les informations des autres routeurs distants du réseau car il joue le rôle de
passerelle pour les autres routeurs, et sera toujours être en train d’être
modifié au fur et à mesure que le réseau s’élargie. Ce qui est devient
dangereux pour le bon fonctionnement du routeur car ayant des ressources
limitées.
 Pour interconnecter n sites, il faudrait configurer n*(n-1)/2 tunnels pour n
routeurs, une équation qui devient difficile à résoudre lorsque le nombre
des sites augmentent et éventuellement lorsque on veut réaliser un réseau
maillé complet ou partiel.
1
Internet Protocol Security, ensemble des protocoles permettant une échange sécurisé des paquets
2
GRE : Generic Routing Encapsulation, protocole de tunneling
INTRODUCTION GENERALE 2
 GRE et IPSec doivent connaître l'adresse d'homologue du point de

terminaison pour monter le tunnel. Les adresses IP3 des routeurs distants
sont de fois octroyer grâce au service DHCP par certains provider pour
élargir leur espace d’adressage.
Face à ces épineuses limites, quelques questions peuvent être soulevées :
1. Comment résoudre cette question épineuse de la multiplicité progressive des

tunnels VPN IPSec pour réaliser un réseau maillé complet ou partiel ?
2. Y’à-t-il moyen de mettre des ‘shortcut ou raccourcis’ pour le trafic entre
Succursales sans passer par le routeur central du réseau ?
3. Comment arrêter cette obligation de modifier les configurations sur le
routeur central du réseau à chaque ajout d’une succursale (Spoke) ?
0.2. Hypothèse
Nous nous sommes posé quelques questions pertinentes dans notre problématique
auxquelles nous tenterons de répondre de manière brève. Après recherche, étude et
réflexion, il en résulte comme suit :
 Concernant l’épineuse question de la multiplicité des tunnels, nous allons

faire usage d’une solution de tunneling qui consistera de mettre en place
un seul canal point-to-multipoint.
 Dans la gestion de notre réseau, nous ferons usage d’une solution de
mappage entre l’adresse du tunnel ainsi que l’adresse publique (adresse
du WAN), opération qui permettra la création dynamique des tunnels entre
les routeurs end-point ou routeurs des succursales.
 Il conviendra également d’user d’une technologie qui permettra de
désengorger le routeur central du réseau de toutes les configurations des
autres routeurs.
0.3. Choix et intérêt du sujet
0.3.1. Choix du sujet
Nous avons porté notre choix sur cette solution afin de permettre une évolutivité
facile et souple d’un réseau VPN IPSec4. Une autre raison qui motive notre choix est
d’optimiser non seulement la communication entre le siège centrale et les succursales
d’une entreprise mais également entre succursales entre elles, en épargnant aux ingénieurs
administrateurs des réseaux VPN IPSec la lourde tâche de configurer des multiples
tunnels pour la réalisation d’un réseau maillé complet ou partiel et d’innombrable
configurations sur le routeur central du réseau.
3
IP : Internet Protocol
4
VPN IPSec : réseau privé virtuel réalisé grâce au protocole IPSec [5, P. 110]
0.3.2. Intérêt du sujet

Ce sujet qui s’intitule « étude d’une mise en place d’une solution de déploiement
d’un réseau VPN IPSec dynamique point-to-multipoint » n’est pas un hasard pour un
futur ingénieur en administration système et réseau, vu son apport qu’il peut apporter aux
entreprises qui peuvent être locales tout comme internationales, en mettant en place une
solution simple et évolutive pour les réseaux VPN IPSec.
Pour la mise en place de ce travail, nous trouvons l’intérêt en donnant trois
points clés ci-dessous :
o Du point de vue personnel : Pour notre formation, c’est pour nous un

grand plaisir de traiter d’un sujet du domaine des réseaux informatiques,
car les recherches sur ce sujet renforceront encore d’avantage nos
connaissances dans ce domaine pour mieux appréhender la notion des
tunnels VPN ainsi que du chiffrement des données avec le protocole
IPSec.
o Du point de vue scientifique : étant donné que ce travail est une œuvre
de recherche, il ne sera pas défendu juste pour l’obtention du diplôme mais
aussi aider les chercheurs qui viendront après nous de trouver une
documentation complète et bien faite pour les guider à faire mieux.
o Du point de vue social : De nos jours l’expansion du réseau d’une firme
est, dans beaucoup de cas, liée à la multiplication des succursales dans le
but de faire accroître son capitale économique, de ce fait la gestion aisée
d’un réseau évolutif et complexe du réseau VPN IPSec est importante et
cette solution est intéressante pour elle.
0.4. L’approche méthodologique

Un travail scientifique suit toujours certaines méthodologies bien définies. Dans
ce cas nous nous sommes basés sur les méthodes et techniques :
0.4.1. Méthodes
 Top down design :Méthode procédant par décomposition du problème,
ce dernier ainsi divisé en certain nombre des sous problèmes, chacun
de complexité moindre. Cette division est ensuite appliquée aux sous
problèmes générés, et ainsi de suite, jusqu’à ce que la résolution de chacun
des sous problèmes soit triviale.
 Analytique : Qui consiste à récolter et d’analyser des informations afin
d’avoir une vue claire de la situation. Cette dernière nous a permis de
mieux faire une étude détaillée des problèmes et limites que posent la
technologie VPN IPSec. Nous le trouverons dans ce travail ;
 Expérimentale : Ici nous sommes passé à la phase de test de notre solution

pour voir le fonctionnement s’il répond à notre attente. Nous le retrouvons
dans le troisième chapitre ;
 L’implémentation : Méthode fondée sur l’expérience scientifique et sur
l’expérimentation, elle nous a permis d’implémenter la solution, de tester
et de vérifier l’hypothèse.
0.4.2. Techniques
 Documentation : il est important pour nous de se référer à une
documentation pour la réalisation de ce travail.
 L’interview : Elle nous a permis d’avoir des échanges avec quelques
personnes susceptibles de nous apporter plus d’éclaircissement dans le
domaine qui concerne notre sujet, entre autres quelques ainés scientifiques.
0.5. Etat de l’art
Nous nous ne permettrons pas de dire que nous sommes les premiers à traiter
sur ce formidable sujet vu que la science évolue à une vitesse comparable à celle
de la lumière, je citerai Julien Berton, qui avait posté un document sur le blog CIEE
ccie.julienberton.fr/2012/10/17/dmvpn-les-tunnels-a-la-demande/ le 20 Octobre 2012 en
présentant l’implémentation de la deuxième phase de la technologie DMVPN;
architecture dans laquelle pour chaque échange entre les routeurs clients du réseau, le
routeur serveur ou concentrateur (Hub) doit être sollicité et en plus les routeurs clients ou
Spokes ne répondais aux requêtes des autres routeurs clients.
Contrairement à Brahim Julien Berton, nous avons voulu proposer
l’implémentation d’un réseau « client vers client », c’est-à-dire présenter une solution
réseau VPN IPSec dans laquelle les routeurs client commence à répondre aux requêtes
des autres routeurs client afin d’améliorer la qualité de service et optimiser la bande
passante, dans le but de rendre toujours fonctionnel le réseau virtuel.
0.6. Délimitation du travail
Il est humainement impossible de réaliser un travail exhaustif. Ainsi notre travail

ne traitera pas tous les aspects relatifs à la construction des réseaux privés virtuels. Il se
limitera à présenter une architecture dans laquelle nous avons un routeur configuré
comme serveur du réseau et trois autres comme clients. Nous ne parlerons pas non plus
de tous les concepts liés à la cryptographie des informations si ce n’est que utilisé ceux
qui seront étroitement liés à la sécurité avec le protocole IPSec.
 Dans le temps : Du mois de Novembre 2016 au mois d’Août 2017, nous

avons préféré mettre en place ce projet parce qu’il est un sujet d’avenir
avec tout cette croissance d’entreprises qui tiendront à élargir le réseau de
leurs entreprises sans pour autant refaire toute une plateforme réseau et
ainsi gagner en temps pour un résultat meilleur.
 Dans l’espace : Ce travail est pris de façon générique afin de laisser une
ouverture à toutes entreprises désirant l’implémentation de cette
technologie pour une évolution souple et facile de leur réseau
0.7. Subdivision du travail

Hormis l’introduction générale et la conclusion générale, notre travail comprendra
trois chapitres. Voici un petit résumé de chaque chapitre en quelques lignes :
 Premier chapitre : « Analyse de l’existant et spécification des besoins du

futur système »
 Deuxième chapitre : « Conception du système»
 Troisième chapitre : « Implémentation du système »
0.8. Outils logiciels et équipements utilisés

La mise en place de ce travail de fin d’études a été réalisée à l’aide de certains
outils logiciels et équipements qu’on peut lister:
o Graphical Network Simulator 3 : Pour la simulation de notre projet ;
o Routeur Cisco 7200 : Avec 12.4 comme version d’IOS ;
o Virtual PC simulator (VPCS) : Des PC virtuels intégrés à GNS3 ;
o Microsoft office Word 2013 : pour le traitement de texte ;
o Microsoft Visio 2013 : outil approprié de la conception assisté par
ordinateur ;
o AstahSysml : pour la modélisation SysML.
Passons, sans plus tarder, au premier chapitre de notre travail et ainsi donner une
idée large sur notre travail.
6
CHAPITRE 1 : ANALYSE DE L’EXISTANT ET SPECIFICATION DES

BESOINS DU FUTUR SYSTEME
1.1. Présentation des VPN

1.1.0. Introduction générale
Dans la mise en place d’un travail scientifique complet, l’étude de l’existant
permet de ressortir les besoins et les fonctionnalités qu’aura le futur système. Pour une
meilleure étude, il faudrait comprendre sur quoi repose l’existant pour une meilleure
approche.
1.1.1. Les réseaux d’entreprises multisites
Les réseaux d’entreprises multisites sont globalement formés de deux grandes

parties importantes, le réseau à l’intérieur de chaque site et le réseau permettant de relier
les sites entre eux. Le réseau à l’intérieur de chaque site peut être vu comme un réseau
monosite.
Le réseau IP intersite doit offrir qualité de service et sécurité. La qualité de
service est fonction soit du réseau de l’organisation elle-même ou celle proposé par
l’opérateur. Suivant l’appartenance du réseau intersite, plusieurs solutions peuvent être
envisagées pour la sécurité. La solution la plus classique consiste à chiffrer les paquets
qui sortent et à les déchiffrer à l’entrée du site distant. Dans ce cas on considère que les
réseaux de site sont sûrs et les accès à ces réseaux sont protégés.
1.1.2. Rappel sur les VPN
Depuis toujours, de plus en plus d’entreprises expriment le besoin

d’interconnecter leurs différents sites distants, tout en assurant une communication
sécurisée, fiable et moins coûteuse. Dans le passé, la meilleure façon de faire
communiquer des sites distants, était l’utilisation des réseaux de la couche deux tels que
le Frame Relay [1, p. 302]. Cependant lorsque chaque site distant possède une connexion
à Internet5, cela change un peu la donne, car dans ce cas le déploiement des réseaux privés
virtuels devient facile et moins coûteux à mettre en place, tout en offrant une
communication sécurisée ainsi que l’expansion facile du réseau virtuel.
Le VPN ou RPV, pour réseau privé virtuel en français, est une technologie
permettant à un ou plusieurs réseaux ou postes distants de communiquer de manière sure,
tout en empruntant une infrastructure publique tel que Internet. Pour assurer la sécurité
5
Internet : interconnexion des réseaux à l’échelle planétaire
ANALYSE DE L’EXISTANT ET SPECIFICATION DES BESIONS DU FUTUR SYSTEME 7
des données échangées, la plupart des VPN utilise des protocoles de chiffrement pour
créer un tunnel de protection et ainsi rendre confidentielle et authentique l’information
échangée entre les deux entités. Ainsi, par exemple, on peut avoir deux réseaux distants
d’une même entreprise reliés à travers un VPN intersite.
1.1.3. Principe de fonctionnement

1.1.3.1. Principe générale
Un réseau VPN [2, p. 475] repose sur un protocole appelé « protocole de
tunneling ». Ce protocole permet de faire circuler les informations de l’entreprise de
façon cryptée d’un bout à l’autre du tunnel. Ainsi, les utilisateurs ont l’impression de se
connecter directement sur leur réseau de leur entreprise.
Le principe de tunneling consiste à construire un chemin virtuel après avoir
identifié l’émetteur et le destinataire. Par la suite, la source chiffre les données et les
achemine en empruntant ce chemin virtuel. Afin d’assurer un accès aisé et peu coûteux
aux intranets6 d’entreprises.
Les données à transmettre peuvent être prise en charge par un protocole
différent d’IP. Dans ce cas le protocole de tunneling encapsule les données en ajoutant un
en-tête. Le tunneling est donc l’ensemble des processus d’encapsulation, de transmission
et de désencapsulation.
1.1.4. Les grandes catégories des VPN

Deux grandes catégories permettent de classifier les VPN en fonction de celui
qui gère le réseau [3, p. 852] :
• Les VPN d’entreprise, qui forment le réseau logique d’interconnexion de
plusieurs sites d’une entreprise, permettent en outre à des utilisateurs
hors des sites de se connecter sur ce réseau logique.
• Les VPN d’opérateurs, qui forment le réseau physique et permettent de
constituer des réseaux logiques pour les entreprises.
1.1.4.1. Fonctionnalités des VPN
Suivant les besoins et les utilisations, les réseaux privés virtuels peuvent être référencés
en 3 types :
 Le VPN d’accès
Le VPN d’accès, ou remote VPN en anglais, est utilisé pour permettre à des
utilisateurs itinérants d’accès au réseau privé de l’entreprise. L’utilisateur se sert de la
connexion Internet pour établir la connexion VPN. Il existe deux cas :
6
Application des technologies internet au sein d’un réseau d’une organisation privée
 L’utilisateur demande au fournisseur d’accès de lui établir une connexion

cryptée vers le serveur distant : il communique avec le serveur d’accès du
réseau du fournisseur d’accès et ce dernier qui établit la connexion cryptée.
 L’utilisateur possède son propre logiciel client pour le VPN auquel cas il
établit directement la communication de manière crypté vers le réseau de
l’entreprise.
Figure 1.1 VPN d'accès
 L’intranet VPN
L’intranet VPN ou le VPN Site-to-site est utilisé pour relier au moins deux
intranets entre eux. Les VPN site-à-site peuvent utiliser les technologies de transport les
plus répandues aujourd’hui, telles que le réseau public Internet ou les réseaux des
fournisseurs d’accès, via le tunneling et le cryptage afin d’assurer la confidentialité des
données et la qualité de service (QoS) pour la fiabilité du transport.
Figure 1.2 Intranet VPN

 L’extranet VPN
Une entreprise peut utiliser le VPN pour communiquer avec ses clients et ses
partenaires. Elle ouvre alors son réseau local à ces derniers. Dans ce cadre, il est
fondamental que l’administrateur du VPN puisse tracer les clients sur le réseau et gérer
les droits de chacun sur celui.
Figure 1.3 Extranet VPN
Cette étude nous a permis de connaitre les implémentations des VPN les plus
répandues en raison de leurs applications courantes. Ces implémentations sont mises en
œuvres en fonction des besoins de l’entreprise en terme de sécurité.
Nous allons passer en révue les différents protocoles qui permettent de déployer
ces différents types de VPN.
1.1.5. Les VPN intersites

Les premiers VPN d’entreprise mis en place étaient de niveau deux. Leurs
rôles étaient de transporter des trames d’un port d’entrée à un port de sortie. Dans ce type
de VPN, les droits d’accès à l’utilisateur sont interconnectés par des circuits virtuels
permanents de niveau trame, qui peuvent provenir d’un relais de trames par exemple.
Les protocoles de couche deux dépendent des fonctionnalités spécifiées pour
PPP , qui est le protocole majeur des VPN de niveau deux, c’est pourquoi nous allons
7
rappeler le fonctionnement de ce protocole.
1.1.5.1. Rappel sur PPP

PPP, Point to Point Protocol, est un protocole qui permet de transférer des
données sur un lien synchrone ou asynchrone. Il est bidirectionnel et garantit l’ordre
7
Point to Point Protocol, protocole majeur des VPN de couche 2
d’arriver des paquets. Il encapsule les paquets IP8, IPX9 de Novell dans des trames PPP,
puis transmet ces paquets encapsulés au travers de la liaison point à point. Le protocole
PPP est défini dans la RFC10 1661 appuyé de la RFC 2153.
Figure 1.4 Format d'une trame PPP
- Fanion : séparateur de trame.

- Adresse : Adresse l’extrémité du tunnel.
- Contrôle : Contrôle de l’intégrité de la trame.
- Protocole : Ce champ identifie le protocole encapsulé dans le champ informations
de la trame. C’est ici que contient le protocole que supporte PPP.
- Données : Ce champ contient le datagramme du protocole supérieur indiqué dans
le champ « protocole ».
- Fcs : ce champ contient la valeur du checksum de la trame.
De nombreux autres types de tunnels peuvent être mis en œuvre pour réaliser
les VPN, mais ces solutions sont plutôt en décroissance aujourd’hui et nous ne pourrons
pas nous attarder dessus [3, p. 16]. On peut citer quelques-uns :
 PPTP11 est un protocole qui utilise une connexion Ppp en créant un réseau
privé virtuel. Pptp est un protocole de niveau deux qui permet l'encryptage
des données ainsi que leur compression. L'authentification se fait grâce au
protocole Ms-Chap de Microsoft.
 L2F12 est un protocole défini par la RFC 2341, reste très peu utilisée.
 L2TP13, pour Layer 2 Tunneling Protocol, est également un protocole de
tunneling de la couche deux. Issu de la convergence des protocoles PPTP
et L2F, L2TP permet d'encapsulation des paquets PPP au niveau des
8
Internet Protocol, Protocole majeur d’Internet
9
Inter-Network Packet eXchange, protocole de communication de Novell
10
RFC : Request for comment, Document présentant la description d’un protocole
11
Point to Point Tunneling Protocol, protocole de tunneling de Microsoft
12
Layer 2 Forwading, protocol de tunneling mis sur pied par Cisco
13
Layer 2 Tunneling Protocol, protocol de tunneling mis au point par l’IETF
couches 2 et 3. L2tp n'intègre pas directement de protocole pour le

chiffrement des données. C'est pourquoi L'IETF préconise l'utilisation
conjointe d'IPSec et L2tp.
MPLS et IPSec sont les solutions de couche trois du modèle OSI qui sont les
plus utilisés de nos jours. Alors, un petit rappel, sur ces deux technologies, fera un peu
plus de lumière dans le choix de la solution meilleure et économique.
1.1.5.2. Le VPN IPSec
1. Présentation du protocole IPSec
IPSec [4] est un protocole qui a été conçu dans le but d’établir une communication
sécurisée grâce à un tunnel entre des entités éloignées, séparées par un réseau jugé non
sécurisé, et ce de manière quasi-transparente.
IPSec fournit trois types de services : l’authentification des deux extrémités, la
confidentialité des données par chiffrement, et la gestion des clés. On l’utilise notamment
pour protéger la connectivité de succursales au travers de l’Internet, et ainsi établir la
connectivité intranet.
2. Composition
Le protocole ISAKMP est le protocole utilisé pour le chiffrement trafic sur un
réseau public tel qu’internet. Il faut configurer une policy ISAKMP qui permet de
déterminer comment est-ce que les clefs seront mise en place soit par une autorité de
certificat soit une clé pré-partagée « pre-shared key »qui est sera l’œuvre de
l’administrateur.
La syntaxe est : crypto isakmp policy <numéro de la policy>
Il faudrait ensuite configurer une transformation IPSec. Une transformation IPSec

contient en fait tous les protocoles et algorithmes nécessaire pour la mise en place d’une
politique de sécurité. les protocoles majeurs sont utilisés pour mettre une transformation
IPSec à savoir ESP et HA [5, p. 110].
- L’intégrité (algorithme de hachage MD5 ou SHA). MD5 utilise

128 bits pour le hachage des données et SHA sur 160 bits;
- L’authentification (l’algorithme HMAC) ;
- Ainsi que la confidentialité (les algorithmes DES, 3DES ou
encore AES) pour le cryptage des informations qui seront
transmises. DES utilise 56 bits, 3DES 168 bits, 128 bits.
Figure 1.5 Protocole AH avec ses algorithmes
Figure 1.6 Protocole ESP avec ses algorithmes
Pour l’application de la sécurité au tunnel, la création ainsi que spécification de la

transformation IPSec déjà créée sont requises. Une transformation décrit un protocole de
sécurité (AH ou ESP) avec ses algorithmes correspondants.
La syntaxe : crypto ipsec profile <nom_du_profile>
set transform-set < nom_de_la_tranformation_IPSec>
Ces deux commandes prennent en paramètre respectivement le nom du profile

IPSec qui est une chaine de caractère sans espace et le nom de la transformation IPSec
qui est également une chaine de caractère sans espace.
Et la dernière opération est l’application du profile au tunnel. La syntaxe est

tunnel protection ipsec profile <nom_du_profile>.
Le protocole IPSec fonctionnement en deux modes distincts :

 Mode transport : Dans le mode transport, ce sont uniquement les données
transférées qui sont chiffrées et bien authentifiées. Le reste du paquet IP est
inchangé et de ce fait le routage du paquet n’est pas modifié, ce mode est
utilisé pour une communication hôte à hôte.
 Mode tunnel : En mode tunnel, c’est la totalité du paquet IP qui est chiffré
ou encore authentifié. Le paquet est ensuite encapsulé dans un nouveau
paquet IP avec un nouvel en-tête IP. Au contraire du mode transport, ce
mode supporte donc bien la traversée de NAT. Le mode tunnel est utilisé
pour créer des réseaux privés virtuels permettant la communication de

réseau à réseau, d’hôte à réseau ou encore d’hôte à hôte.
IPSec crypte le trafic entre deux points de terminaison homologues, et le

cryptage est fait entre les deux points de terminaison. La limite avec IPSec est qu’il ne
prend pas en charge le chiffrement des trafics de type multicast.
3. Le protocole de tunneling
IPSec, étant est un protocole qui permet le chiffrement du trafic, ne prend pas en
charge le trafic de type multicast tel que les mises à jours des tables d’un routeur comme
nous l’avons signalé déjà signaler, donc il est capable de transporter les mises à jour
émises par les routeurs. La manière la plus pratique est de trouver un protocole capable
de transporter le trafic de type multidiffusion pour l’annonce dynamique des routes
réseaux et ainsi éviter l’opération fatidique de remplir la table de routage manuellement.
 Le protocole GRE
GRE [6], pour Generic Routing Encapsulation, est un protocole de tunneling

VPN site to site de base, non sécurisé beaucoup plus utilisé au niveau de la couche trois.
Le protocole GRE, développé par Cisco, est un protocole capable d’encapsuler une large
variété de types de paquets de protocoles au sein de tunnels IP. Ce protocole possède une
variante, mGRE, pour multipoint Generic Routing Protocol. Ce dernier ne fait pas du
point à point comme le GRE mais le point à multipoint.
Figure 1.7 Diagramme de flux d'encapsulation avec le protocole GRE

GRE étant un protocole non sécurisé, il est très souvent utilisé avec le protocole
IPSec afin d’apporter la sécurité non seulement des informations transmises mais
également des entités communicantes.
Figure1.8 VPN GRE over IPSec
1.1.5.3. Le VPN/MPLS
Une solution de plus en plus utilisée par les opérateurs consiste à utiliser des
VPN réalisés par un réseau MPLS [6]. Les différentes liaisons entre les accès aux sites de
l’entreprise sont matérialisées par des chemins privés, ou LSP (Label Switched Path)
privés, sur lesquels un chiffrement peut éventuellement être ajouté de façon à augmenter
la sécurité du transport.
Le principe de fonctionnement de MPLS est la commutation de labels. Ces
labels, simples nombres entiers, sont insérés entre les en-têtes de niveaux deux et trois,
les routeurs permutent alors ces labels tout au long du réseau jusqu’à la destination, sans
avoir besoin de consulter l’en-tête IP et leur table de routage.
Des tunnels sont créés entre des routeurs MPLS de périphérique appartenant à
l’opérateur et dédiés à des groupes fermés d’usages particuliers, qui constituent des VPN.
Dans l’optique MPLS/VPN, un VPN est un ensemble de sites placés sous la même
autorité administrative
Une terminologie particulière est employée pour désigner les routeurs, en
fonction de leur rôle, dans un environnement MPLS/VPN :
 P (Provider) : ces routeurs, composant le Backbone MPLS, n’ont
aucune connaissance de la notion de VPN. Ils se contentent
d’acheminer les données grâce à la commutation de labels ;
 Pe (Provider Edge) : ces routeurs sont situés à la frontière du Backbone
MPLS et ont par définition une ou plusieurs interfaces reliées à des
routeurs clients ;
 Ce (Custommer) : ces routeurs appartiennent au client et n’ont aucune

connaissance des VPN ou même de la notion de label. Tout routeur
simple peut être un routeur Ce, quel que soit son type ou la version
d’IOS utilisée.
Figure 1.9 Architecture d'un VPN/MPLS
1.1.6. Choix d’un VPN de couche trois

Cette étude des solutions VPN, met en évidence une forte concurrence entre les
ces deux technologies. Néanmoins, il est possible de distinguer qu’il y a une forte
concurrence entre ces deux rivaux sortant leurs épingles du jeu par rapport aux VPN de
couche deux, à savoir IPSec et MPLS. En effet, la mise en place de VPN entre
généralement dans une politique de réduction des coûts liés à l'infrastructure réseau des
entreprises.
La solution VPN à base de MPLS pouvait continuer à prendre le devant face aux
technologies IPSec s’il n’existait aucune solution VPN IPSec qui pouvait rendre possible
l'intégration de solution de téléphonie sur IP. Cependant il existe un certain nombre de
solution VPN IPSec qui prenne en charge la voix sur IP ce qui casse l’ascension que le
VPN MPLS avait sur le VPN IPSec. Vous avez bien compris nous allons intéresser sur
différentes solutions VPN IPSec pour voir leur fonctionnement ainsi que les avantages.
Le choix étant fait nous allons nous intéresser aux différentes existantes les plus en vue à
fin d’élire celle qui sera implémenté dans le troisième chapitre.
1.2. Présentation et critique sur l’existant

Avant tout, pour une meilleure compréhension du fonctionnement d’un réseau
VPN IPSec point-to-point s’impose. Nous pouvons l’expliquer à l’aide de ce diagramme
de séquence.
Figure 1.10 Diagramme de séquence du fonctionnement d'un tunnel VPN IPSec
Sur cette figure 1.10 nous avons le premier acteur qui émet une information, cette
information est encapsulée dans le protocole GRE qui va assurer son transport. Comme
GRE n’est pas sécurisé, des mécanismes de sécurité seront appliquer sur ce nouveau
paquet grâce au protocole IPSec, et par après le paquet va être envoyé vers la destination.
A son arriver, une fois le paquet reçu, il va être traité en fonction des paramètres de
sécurité qu’il contient. Une fois fait, le paquet sera desencapsulé puis dirigé vers l’hôte
final.
1.2.1. VPN site to site (Intranet VPN)
Figure 1.11 VPN Site-to-site

La manière la plus classique, pour les entreprises multisites de construire un

réseau VPN IPSec évolutif, est de l’organiser en étoile. Le routeur siège centrale de
l’entreprise, configuré comme étant le point central du réseau ou concentrateur, auquel se
connectent les routeurs des différents sites distants ou succursales de l’entreprise.
Figure 1.12 Architecture d'un réseau VPN en étoile
En utilisant Internet comme moyen d’interconnexion entre le siège centrale et les

différentes succursales, il serait mieux que les succursales aillent accès direct entre eux
sans frais supplémentaires. Mais il est difficile, voire impossible, d’installer ou gérer un
réseau maillé complet ou partiel. Les réseaux maillés complets ou partiels sont souvent
souhaitables parce qu’il peut y avoir des économies de coûts si le trafic de routage entres
succursales peut se faire, au lieu de passer toujours par le siège centrale. Nous l’avons
compris, pour que deux succursales puissent communiquer le trafic doit remonter vers le
routeur Concentrateur avant d’arriver à destination. Cela devient un problème car le trafic
utilise ses ressources et peut provoquer des délais, particulièrement en utilisant le
cryptage IPSec, puisque le routeur du siège central devra crypter les paquets des routeurs
émetteurs des succursales, puis recrypter le trafic pour l’envoyer au routeur destinataire.
Un autre exemple ou le trafic de route direct entre succursales serait utile, et le cas ou
deux succursales sont dans la même ville et le siège central se trouve à l’autre bout du
pays.
Figure 1.13 Architecture d'un réseau VPN maillé partiel
Ces limites ont occasionnées la mise en place de certaines solutions qui

permettront de passer outre tous problèmes cités, et ainsi rendre facile et souple
l’évolution d’un réseau VPN IPSec, ce qui fera le sujet de la suite de notre travail.
Avant d’évoluer voyons à quoi ressemble le vrai problème sur lequel part notre
travail en donnant un exemple d’une configuration d’un VPN IPSec point-à-point entre
deux sites.
1.2.2. Mise en place d’un VPN IPSec

o Exemple de configuration place d’un VPN IPSec site-to-site
Prenons l’exemple d’une architecture d’un réseau VPN IPSec site-to-site en

mettant en place une configuration basique.
Nous avons une architecture possédant 4 routeurs dont un pour le siège central de
l’entreprise et les 3 autres pour des sites distants ou succursales de l’entreprise. A signaler
que le routeur Rn spécifie un nième site distant de l’entreprise. Les détails sont les suivants :
2. R1 possède sur son interface S0/0/0 une adresse IP publique qui est
80.1.0.5/24, une interface de loopback nommé loopback0 pour simuler un
réseau ayant comme adresse 192.168.1.1/24, un premier tunnel nommé
tunnel0 allant vers R2 qui a comme adresse 10.0.0.1/30, un deuxième tunnel
nommé tunnel 1 allant vers R3 qui a comme adresse 10.0.0.5, un troisième
tunnel nommé tunnel n qui va vers le routeur Rn qui a comme adresse
10.0.0.n.
30.0.0.5/24, une interface de loopback nommé loopback0 ayant comme
adresse 192.168.2.1/24 et un tunnel nommé tunnel0 allant vers R1 possédant
comme adresse 10.0.0.2/30.
40.21.0.8/24, une interface de loopback nommé loopback0 ayant comme
adresse 192.168.3.1/24 et un tunnel nommé tunnel0 allant vers R1 possédant
comme adresse 10.0.0.6/30.
Figure 1.14 Exemple d'un VPN site-to-site
Se rapportant à la figure de l’architecture ci-haut, nous pouvons jeter un coup

d’œil sur la configuration d’un tunnel VPN IPSec point-to-point. Pour cet exemple nous
prendrons l’exemple de la configuration du tunnel 0 entre le routeur concentrateur R1 et
le routeur client ou Spoke R2.
o Configuration du tunnel sur le routeur concentrateur
Voici la configuration sur le routeur concentrateur qui consiste à renseigner

l’adresse publique de l’hôte distant avec lequel on veut établir la liaison VPN, qui est R2.
Pour notre exemple, la configuration simple et classique d’un tunnel IPSec sur les
routeurs, on renseigne les éléments suivants :
- Une politique de sécurité IPSec (policy) portant un numéro identifiant ;

- La sécurité IPSec avec le protocole ISAKMP avec la configuration d’une
transformation IPSec (Transform-set) : Dont les paramètres sont le protocole de
sécurité ESP, l’algorithme de hachage MD5 pour l’intégrité, la fonction

d’authentification avec le protocole HMAC ;
- Déterminer l’adresse source tunnel ;
- Déterminer l’adresse de destination du tunnel ;
- Une policy ISAKMP pour la sécurité avec comme méthode de sécurité des clés
pré-partagées (pre-share).
Router#configure terminal
Router(conf)#hostname R1
R1(conf)#crypto isakmp policy 1
R1(conf)#authentication pre-share
R1(conf)#crypto isakmp key votreclef address 0.0.0.0
0.0.0.0
R1(conf)#crypto ipsec transform-set trans2 esp-des esp-
md5-hmac mode transport
R1(conf)#crypto map vpnmap1 10 ipsec-isakmp s0/0/0
R1(conf)#match address 101
R1(conf)#set address 30.0.0.5
R1(conf)#set transform-set trans2
R1(conf)#interface Tunnel0
R1(conf-int)#ip address 10.0.0.1 255.255.255.252
R1(conf-int)#tunnel source s0/0/0
R1(conf-int)#tunnel destination 30.0.0.5
R1(conf-router)#access-list 101 permit gre host
80.1.0.5 host 30.0.0.5
Figure 1.15 Configuration du tunnel VPN sur R1
En regardant la configuration du routeur R1 ci-dessus, vous pouvez constater qu’il

y’à peu près 10 lignes de configuration pour le tunnel vers routeur distant R2, 4 pour la
clé de cryptage, 1 pour la liste de contrôle d’accès pour cryptage et 5 pour l’interface du
tunnel GRE.
o Configuration du tunnel sur le routeur concentrateur

Même configuration sur le routeur distant en changeant seulement l’IP publique

qui sera cette fois ci celle de l’hôte distant qui est le routeur concentrateur du réseau avec
lequel on veut établir la liaison VPN.
Router#configure terminal
Router(conf)#hostname R2
R2(conf)#crypto isakmp policy 1
R2(conf)#authentication pre-share
R2(conf)#crypto isakmp key votreclef address 0.0.0.0
0.0.0.0
R2(conf)#crypto ipsec transform-set trans2 esp-des esp-
md5-hmac mode transport
R2(conf)#crypto map vpnmap1 10 ipsec-isakmp s0/0/0
R2(conf)#match address 101
R2(conf)#set address 80.1.0.5
R2(conf)#set transform-set trans2
R2(conf)#interface Tunnel0
R2(conf-int)#ip address 10.0.0.2 255.255.255.252
R2(conf-int)#tunnel source s0/0/0
R2(conf-int)#tunnel destination 80.1.0.5
R2(conf-router)# access-list 101 permit gre host
30.0.0.1 host 80.1.0.5
Figure 1.16 Configuration du tunnel sur R2
Imaginons maintenant le nombre de ligne qu’aura le routeur concentrateur du

réseau ou le routeur R1 dans le cas où il faudra réaliser une configuration d’un réseau
d’une entreprise possédant 30 sites distants. Si on fait bien des calculs on aura 13 multiplié
par 30 ce qui donnera 360 lignes de configurations. En plus de cela pour réaliser un réseau
maillé en utilisant la formule n*(n-1)/2 dont n est le nombre des routeurs, on aura à
configurer 435 tunnels ce qui est visiblement fatigant à maitre en place.
1.2.3. Point forts

 Réductions des coûts : les VPN de niveau 3 permettent aux entreprises d'utiliser
un transport Internet tiers et économique pour la connexion des bureaux et des
utilisateurs distants au site principal, éliminant par conséquent le besoin de
disposer de liaisons WAN et ainsi diminuer leurs coûts de connectivité.
 Sécurité : les VPN peuvent inclure des mécanismes de sécurité offrant un niveau
de sécurité très élevé grâce à l'utilisation de protocoles de chiffrement et
d'authentification avancés qui protègent les données de tout accès non autorisé.
 Évolutivité : les VPN permettent aux entreprises d'utiliser l'infrastructure
d'Internet des FAI et des périphériques, ce qui permet d'ajouter facilement de
nouveaux utilisateurs. Les grandes entreprises peuvent ajouter des volumes
importants de capacité sans ajouter d'infrastructure importante.
1.2.4. Point à améliorer
 Eliminer l’obligation de configurer chaque tunnel sur le routeur du siège centrale

pour chaque point de terminaison ou pour chaque succursale et ainsi utiliser un
seul tunnel pour toutes les succursales.
 Maitriser le mappage entre l’adresse IP privé du tunnel avec l’adresse publique
de l’interface WAN pour la création dynamique des tunnels périodiques entre
Spoke.
 Mettre en place une solution de communication site-to-site sans passer par le
routeur serveur du siège centrale.
 Eviter de centraliser toutes les configurations de toute l’architecture réseau sur le
routeur du siège central.
1.3. Spécifications des besoins
Le système ne naissant pas au hasard, la question du choix des composants qui le
constituent n’est pas anodine. Ce choix doit reposer sur des critères objectifs et
justifiables.
1.2.1. Les Exigences du futur système
- Les besoins business : définissent des exigences qui permettront de mettre en
place une solution réseau économique, à moindre coût et efficace. De ce fait il
sera question dans ce travail de proposé aux entreprises un livrable qui leur
permettra de mettre en place et de gérer leur propres réseaux VPN IPSec pour la
réduction sensible des coûts et dépenses liés aux infrastructures des Fournisseurs
de ces types de service et ainsi permettre un total contrôle et une gestion de leur
propre réseau virtuels.
- Les besoins fonctionnels : expriment une action que doit effectuer le système en
réponse à une demande (sorties qui sont produites pour un ensemble donné
d’entrées). Le futur système VPN qui sera choisie parmi tant d’autres devra être
capable d’assurer correctement les principales fonctionnalités d’un réseau privé

virtuel à savoir l’authentification des entités communicantes, l’intégrité des
données échangées ainsi que la confidentialité des informations échangées.
- Les besoins non fonctionnels : représentent les exigences implicites auxquelles
le système doit répondre. En plus des fonctions primaires, la solution devra être
capable de supporter différentes contraintes liées au fonctionnement et à
l’élargissement du réseau virtuel.
Voici un tableau reprenant tous les besoins fonctionnels et non fonctionnels
affiliés aux différents besoins business qui permettront un déploiement d’un système
économique d’interconnexion de différents sites distants qui composent une entreprise.
Tableau 1.1 Définition des exigences du futur système
Id Exigences Exigences Fonctionnelles et Exigence techniques

Business non fonctionnelles
1 Interconnexion - Mise en place facile des - Choix d’une solution
des sites distants à réseaux privés virtuels entre VPN qui permettra
moindre coût sites distants ; même un choix
- Evolutif stratégique des
- Sécurité assurée ; routeurs pour un
14
- Scalabilité ; réseau évolutif
- Performant
- Stabilité.
2 Assurer la qualité - Economique (en termes de
de service bande passante) ; -
- Réduire les délais d’attente ;
Pour une meilleure compréhension de ces exigences la figure 1.17, représentant

un diagramme d’exigences SysML, regroupe les différents les différentes exigences
auxquelles doit répondre notre futur système.
14
Capacité d’un système à s’adapter et à maintenir ses fonctionnalités et ses performances en cas d’un
changement majeur.
Figure 1.17 Diagramme SysML des exigences fonctionnelles et techniques du futur système
25
1.3 Conclusion partielle
Cette étude nous a permis de nous focaliser sur les problèmes et difficultés
réels, qui caractérisent les réseaux VPN IPSec actuels dans leurs mises en place pour un
réseau expansion. Ainsi donc, cela nous permettra de mettre en place une solution
optimale répondant aux besoins réels présentés dans ce travail, en tenant bien sur compte
des contraintes réelles.
Ainsi dans le chapitre suivant, nous mènerons une étude comparative sur
différentes solutions. Nous en dégagerons les avantages, les limites et méfaits en vue d’un
meilleur choix sur la solution qui sera adoptée et implémenté par la suite.
26
CHAPITRE 2 : CONCEPTION DU SYSTEME
2.1. Introduction
Un système étant un ensemble des composants solidement agencés pour la
réalisation d’un but précis. La configuration de chaque composante devra être
soigneusement optimisée pour créer un système qui répond aux objectifs ultimes pour
lesquels il a été conçu. Ainsi, la tâche de concevoir un système commence par une étude
approfondie des fonctions requises. Et la forme découlera de toutes ces exigences.
2.2. La méthodologie Top down design

Albert Einstein a dit : « le monde que nous avons créé en raison du niveau de
réflexion que nous avons atteint jusqu’à présent engendre des problèmes que nous ne
pouvons résoudre au même niveau auquel nous les avons créés »
Pour paraphraser Einstein, les concepteurs d’un système sont capables de mettre
en place des systèmes si complexes qu’en cas problèmes il faudra faire une segmentation
modulaire pour mieux envisager un dépannage. Cette division est ensuite appliquée aux
sous problèmes générés, et ainsi de suite, jusqu’à ce que la résolution de chacun des sous
problèmes soit trivial.
Figure 2.1 Niveau d'abstraction appliqué à la conception
2.3. Conception générale
Dans l’ensemble des besoins qui se sont posés, il est impératif dans ce travail
de mettre en place une solution de gestion du réseau logique qui devra combiner la
CONCEPTION GENERALE 27
réduction du coût dans la gestion de la bande passante, scalabilté ainsi que la stabilité et
par-dessus, tout en offrant une évolutivité facile du réseau VPN.
De manière sommaire, l’architecture générale de notre topologie est constitué

des types de routeurs, Hub ou concentrateur du réseau qui est le routeur coordonnant
toutes les échanges du réseau ainsi que des routeurs clients ou Spokes. Les routeurs du
réseau VPN sont reliés par deux catégories des tunnels :
Nous pouvons également constater qu’il y’a conceptuellement deux catégories de

tunnels :
- Un tunnel statique : le tunnel statique est une liaison permanente entre le routeur
serveur avec le routeur client. Il permet de maintenir la communication
permanente entre les deux types de routeurs et ainsi permettre au routeur Client
d’émettre des requêtes au routeur Serveur.
- Un tunnel dynamique : c’un tunnel de communication entre les routeurs clients.
Créer après la résolution du bond ou saut suivant par le routeur serveur, ce tunnel
permet de mettre en place une communication directe entre routeurs clients sans
passer par le routeur serveur.
2.4. Conception détaillée
Maintenant que nous avons présenté superficiellement notre architecture, il est

temps que nous descendions à un niveau d’abstraction plus bas en faisant un zoom sur les
différentes parties qui la constitue.
2.4.1. Conception détaillée logique
En parlant de la conception détaillée logique nous voyons l’étude séparative des

différents composants constituant un système complexe à fin de saisir chaque
fonctionnement modulaire et ainsi comprendre son apport dans l’ensemble du système.
La conception détaillée logique nous permettra de présenter notre solution en des
séquences modulaires dans le but de réduire son niveau d’abstraction et ainsi comprendre
son fonctionnement et par la suite élire la solution qui répondra au mieux à nos objectifs
business.
Le réseau VPN IPSec est constitué intrinsèquement des tunnels points to points
entre les différents sites distants. L’évolution de ce type de réseau étant difficile à
maitriser, il existe une solution appelé DMVPN15, qui signifie Dynamic Multipoint
Virtual Private Network.
15
Dinamic Multipoint Virtual Private Network
Le DMVPN [8] est en réalité un ensemble de technologies qui sont IPSec,

GRE et NHRP qui, une fois combinées, facilite le déploiement des réseaux privés
virtuels IPSec. Il s’agit d’une solution fiable, sécurisée et évolutive, permettant une mise
en place et une gestion souples des tunnels IPSec. Le DMVPN propose trois manière
d’être implémenter à savoir Le DMVPN phase 1, Le DMVPN phase 2 et le DMVPN
phase 3
2.4.2. Etude des composants de la solution DMVPN

Avant de commencer à parler du fonctionnement des différentes phases
DMVPN, qui à l’issue de leur comparaison en découlera la solution qui répond le mieux
à nos exigences business, il sera important parler de ses différents composants pour mieux
appréhender son fonctionnement. Il est composé de :
- Le protocole mGRE
- Le protocole IPSEC
- Le protocole NHRP
- Et soit avec le routage statique ou au moyen d’un protocole de routage
dynamique.
Tableau 2.1 Composant de la solution
ID COMPOSANT DESCRIPTION BUT

1 mGRE Multipoint Generic Routing Ce protocole de tunneling
Protocol, Un protocole de utilisé pour encapsulé une
tunneling grande variété d’autres
protocoles tels que IP ou IPX.
2 IPSEC IP Security, protocole Ce protocole est utilisé pour

utilisé chiffrer le trafic qui sera
encapsulé dans le protocole
GRE qui n’intègre pas de
mécanisme de sécurité.
3 NHRP Next-Hop Résolution C’est le protocole utilisé pour

Protocol, est un protocole déterminer le prochain saut
de résolution de saut suivant sur le réseau public. NHRP est
ou bond suivant. utilisé pour réaliser le
mappage entre l’adresse
publique et celle du tunnel et
ainsi permettre la création

dynamique des tunnels.
4 Soit le routage Le routage est le processus L’annonce des différentes

statique soit le qu’un routeur utilise pour routes des différents LAN
routage transmettre des paquets vers interconnectés.
dynamique un réseau de destination.
1. Le protocole NHRP (Next Hop Resolution Protocol)
Le protocole NHRP [7] est un protocole de résolution du prochain bond permet à une
station source (hôte ou routeur), qui souhaite communiquer sur un sous-réseau de non
diffusion, multi accès de déterminer les adresses IP d’une passerelle distante et les
adresses NBMA des "prochains bonds NBMA" convenables vers une station de
destination.
1.1. Terminologie
Dans l’implémentation de la solution DMVPN, deux termes sont à considérer : "

Hub " et " Spoke " selon son le rôle qu’il est appelé à jouer :
- Le serveur NHS, le Hub ou encore le routeur Concentrateur : C’est une entité

qui effectue le service du protocole de résolution du prochain bond au sein du
nuage NBMA. Un NHS est souvent couplé à une entité d’acheminement. Maître
d’un réseau comme un routeur, l’entité est appelé coordonner les différentes
échanges entre client ou NHC du réseau et répondre à leur différents requêtes. Un
NHS est dit « serveur » car c’est l’entité d’acheminement qui fait office du
résolveur du prochain bond pour d’autres entités dit « client » ou NHC.
- Le client NHC, routeur client ou encore Spoke : C’est une entité qui initie des
demandes NHRP de divers types afin de d’obtenir l’accès au service NHRP.
1.3. Fonctionnement
Pour le bon fonctionnement du réseau avec le protocole NHRP, il existe trois types
de requêtes les routeurs du réseau peuvent utiliser. Ces requêtes sont :
- NHRP Registration Request : Requête émise par un routeur Spoke à
destination routeur Hub qui est le serveur NHS pour l’enregistrement de
son mappage IP privé du tunnel et IP privée de son interface physique.
Cette requête est requise pour la construction du tunnel entre le Spoke et
le Hub.
- NHRP Resolution Request : Requête de résolution de saut suivant.
- NHRP Résolution Reply : Réponse à une NHRP Resolution Request.

- NHRP Redirect : Requête envoyée par le Hub aux Spoke afin de lui
permettre de réécrire sa table CEF16 et le table pour de mappage NHRP du
saut suivant pour l’établissement des tunnels entre Spokes.
 Enregistrement des Spokes sur le Hub
Dans la configuration des Spoke, l’adresse du tunnel sur routeur Hub est
renseignée pour les différentes les routeurs Spokes du réseau et vice versa afin d’établir
une communication permanente entre le(s) serveur(s) et les clients.
1. Le routeur Spoke commence par envoyé une requête

d’enregistrement « NHRP Registration Request » au serveur NHS qui
est le routeur Hub, qui est en soi le mappage de son adresse IP de son
tunnel avec son IP publique ou NBMA17.
2. Le routeur Hub réceptionne cette requête, met à jour sa table de
mappage et déclenche automatiquement le tunnel permanent avec le
routeur Spoke.
3. Par la suite, le routeur Hub envoie une réponse au routeur Spoke lui
confirmant la réussite de son enregistrement.
Figure 2.2 Enregistrement du Spoke sur le Hub
 Communication Hub et Spoke

Le routeur Concentrateur ou Hub est serveur du réseau qui coordonne tous le
réseau et répond à toutes les requêtes des clients. Etant le serveur NHS, le routeur Hub se
charge de faire connaitre les réseaux distants des différents clients les uns aux autres en
acheminant les mises jours que les clients lui envoient. Se trouvant dans une architecture
client-serveur, routeur Hub assure les différentes fonctions telles que :
16
Cisco Express Forwading
17
Non Broadcast Multi Access
o La coordination des trafics de tout le réseau ;

o Se charge de la propagation des mises à jour entre Spokes qu’il reçoit des
uns vers les autres ;
o Répondre aux différentes « requests » ou requêtes des clients pour la
formation dynamiques des tunnels dans certaines phases ou manières
d’implémentation du DMVPN.
Figure 2.3 Paquets de communication entre Hub et Spoke
2.4.3. Les Solutions VPN IPSec
A l’heure actuelle plusieurs solutions existent pour l’implémentation d’un réseau

VPN IPSec évolutif, Néanmoins trois technologies émanant d’une seule technologie
semble avoir le vent en poupe par rapport aux autres et propose une bien meilleure
solution. De ce fait nous allons faire une étude comparative et objective afin d’élire celle
qui sera appropriée conformément aux exigences business du premier chapitre.
Nous rappelons que cette solution peut être déployée en trois différentes phases,
différentes les unes des autres. A noter le terme phase signifie tout simplement une
proposition de la solution DMVPN. Les effets de ces différentes phases sont les suivants :
- Le comportement du trafic entre les routeurs dits Spoke est différents pour
chacune de ces phases.
- Les design de routage supportés par les différentes phases ne sont pas les mêmes.
- L’évolutivité du réseau est impactée par ces différentes phases.
a) Le DMVPN Phase 1
La première phase du DMVPN est dite la phase Hub and Spoke. Dans cette phase
les Spokes peuvent seulement joindre le Hub. Le tunnel qui lient le routeur Hub ou au
routeur Spoke étant permanent, il reste le seul moyen de communication entre les routeurs
Spokes. Lors de son implémentation, Tout trafic quittant un LAN d’un routeur Spoke à
destination d’un autre LAN d’un routeur Spoke est obligé de passer par le routeur Hub
du réseau car il n’y a aucune communication directe entre les routeurs Spokes.
o Fonctionnement
Les Spokes enregistrent leurs adresses IP des tunnels avec l’adresse

NBMA ou leurs adresses sur le serveur NHS qui est le routeur concentrateur ou le routeur
Hub du réseau afin qu’il sache les joindre. Le protocole de routage envoie les informations
depuis le Hub vers le Spoke afin que tous les routeurs du réseau mettent à jour leur table
de routage pour une meilleure connaissance du réseau.
La phase 1 de la solution présente certaines avantages tels que :
 Cette phase, reste tout de même très avantageuse car la configuration du

routeur Concentrateur ou Hub est simplifiée.
 Dans la solution DMVPN phase 1, l’administrateur n’a pas besoin de
mapper l’adresse IP du tunnel et l’adresse IP publique sur tous les
routeurs du réseau pour un nouveau Spoke qui peut s’ajouter au réseau.
L’inconvénient que présente la phase 1 de la solution DMVPN est l’impossibilité d’établir
des tunnels directes entres les routeurs Spokes.
o Avantages
- La décentralisation des configurations des tous les Spokes sur le routeur
Hub du réseau ;
- L’élimination de multiplicité des tunnels sur le routeur Hub du réseau.
o Désavantage
- L’incapacité d’établir des tunnels entre les Spokes dans le réseau ce qui
veux dire incapacité de réalisé un réseau maillé complet.
Figure 2.4 Fonctionnement de la phase 1 DMVPN
b) Le DMVPN phase 2
L’implémentation de la phase deux permet d’avoir des tunnels directs et

dynamiques entre les routeurs Spokes du réseau, chose rendu possible par la configuration
des interfaces mGRE sur les interfaces des routeurs.
o Fonctionnement
Son fonctionnement est tel que, lorsqu’il y a un trafic provenant d’un LAN d’un
Spoke, dans ce cas Spoke aura besoin de déterminer le saut suivant du routeur de
destination pour la construction du tunnel direct et d’une manière dynamique. Alors le
routeur va émettre un paquet de type « NHRP Resolution Request » au routeur Hub qui
est le serveur NHS pour la résolution du saut suivant. Le routeur Hub va consulter sa table
de mappage afin de savoir quelle adresse IP publique est mappée à l’adresse IP privée
contenue dans la requête. Le routeur Hub va répondre en émettant un paquet de type
« NHRP Résolution Reply » comme une réponse contenant l’adresse IP publique mappé
à l’adresse IP privée du tunnel du routeur Spoke de destination. Alors le Spoke peut
monter dynamiquement le tunnel avec le routeur de destination.
o Avantage
- La réduction de la multiplicité des tunnels sur le Hub ;

- La décentralisation des configurations des Spokes sur le Hub ;
- L’avantage majeur que présente la phase 2 DMVPN est l’établissement des
tunnels dynamique entre les Spoke sans passer par le Hub. Ces tunnels sont dits
« tunnel à la demande » car ils sont établis seulement lorsque il y’a un trafic
quittant un Spoke vers un autre Spoke ;
- Possibilité de réaliser un réseau maillé complet.
o Désavantage
- Pour l’établissement d’un tunnel entre Spoke vers un autre Spoke, le serveur doit
être sollicité.
c) Le DMVPN phase 3
Tout comme la phase deux, tous les routeurs du réseau sont configuré en
mGRE et sur le routeur concentrateur du réseau (Hub). Et sur les routeurs client ou Spokes
du réseau. Dans cette phase, on ajoute une redirection NHRP qui permet aux routeurs
Spokes d’établirent des conversations Spoke-to-Spoke de joindre directement les Spokes
sans passer par le Hub et aussi réécrire leur table CEF.
NHRP phase 3 utilise les Spokes qui répondent maintenant aux NHRP
Resolution Request. Ce qui fait que le Hub n’est plus le seul à détenir les informations
NHRP.
o Fonctionnement
1ère étape : Les Spokes enregistrent leur table de mappage Tunnel/Adresse publique
avec le Hub. Cela permet au Hub de découvrir dynamiquement les Spokes et établir les
relations de voisinage. Ensuite ils peuvent échangés les mises à jour de routage.
2ème étape : Les Spokes reçoivent les informations de routage, et remplissent leurs
tables CEF. Plus d’entrée CEF invalide, elles sont toutes complètes. Dorénavant dans
cette phase, les Spokes s’appuient sur le paquet NHRP Redirect message.
3ème étape : Un tunnel mGRE est configuré pour les NHRP Redirects. Quand le
routeur Hub reçoit un paquet IP en entrée de son tunnel mGRE, et le renvoi sur la même
interface. Il renvoie à la source un NHRP Redirect. Ce message demande à la source que
le chemin n’est pas optimal, et qu’il devrait plutôt trouver un meilleur chemin via la
NHRP Resolution.
4ème étape : Maintenant, le Spoke reçoit le NHRP Redirect. Ce dernier va envoyer

une NHRP Request vers les autres Spokes du réseau. La requête voyage sur tous les
Spokes jusqu’à ce qu’elle trouve la cible. Ce fonctionnement est normal pour une
architecture peer to peer.
5ème étape : Maintenant les Spokes peuvent également commencer à répondre à la

résolution. Basé sur l’IP source présente dans le payload 18 du paquet, il trouve le Spoke
correspondant dans sa table de routage. Il utilise l’IP NBMA du routeur source et renvoi
un NHRP Reply directement (sans retraverser le Hub). La réponse arrive sur le routeur
source et il connait alors l’IP NBMA de sa destination. Maintenant, en plus de réécrire la
table NHRP, le routeur réécrit l’entrée CEF.
18
La charge utile d’un paquet IP qui contient les données transportées ainsi que l’adresse source de
l’émetteur
o Avantages
- Cette phase peut être également appelée « une phase Spoke to Spoke » car dans
cette phase, les routeurs Spokes sont maintenant capables de communiquer
directement et sans avoir besoin de commencer à interroger le routeur Hub à tout
moment pour la résolution du saut suivant dans le réseau DMVPN. Ainsi le
routeur Hub devient désengorger et de moins en moins solliciter pour la
communication entre les routeurs Spokes.
o Inconvénient
- Les premiers trafics de résolution du saut suivant quittant un Spoke vers un autre
consomme un peu en ressource sur le réseau.
2.4.4. Choix Technologiques
Maintenant que nous maitrisons toutes les « briques élémentaires » qui composent
chaque solutions après cette comparaison synthétique de différentes solutions, et
connaissant les exigences sur lesquels reposent notre le choix de notre solution, nous
pouvons à présent passer à l’élection de celle qui répondra le mieux à nos besoins et nous
permettra d’atteindre notre objectifs ultime.
Pour le choix de la solution à implémenter nous allons faire une

comparaison entre les solutions VPN IPSec présentées ci-haut à savoir le DMVPN phase
1, phase 2 et phase 3. Les choix des différentes solutions technologiques ne seront pas
faits de façon arbitraire, nous allons faire recours aux exigences fonctionnelles et non
fonctionnelles que nous avons définies dans le premier chapitre. Ces dernières vont nous
servir de critères de choix pour la meilleure solution technologique. Les critères sont
évalués sur base des mentions « Faible » qui vaut 1.5, « Moyen » 3 et « Fort » 4.5 points,
ce qui fera un total de 30 points vu leur nombre qui est de 6. Les solutions qui seront
retenues seront celles qui auront les plus grandes cotes sur 30.
Les critères de choix sont donc les suivants :
Critère 1 (C1) : La qualité de service (QOS) : est la capacité pour un système à

fournir un service conformément à des exigences en matière de
temps de réponse et bande passante.
Critère 2 (C2) : Evolutivité, représente la capacité pour un système de s’élargir

sans problème ;
Critère 3 (C3) : Sécurité, nous voyons un système dont l’accès est contrôlé et
maitrisé ;
Critère 4 (C4) : Scalabilité, Capacité d’un système à s’adapter et à maintenir ses

fonctionnalités et ses performances en cas d’un changement
majeur ;
Critère 5 (C5) : Performance, capacité d’un système à avoir un temps d’attente

moindre ;
Critère 6 (C6) : Stabilité, capacité pour un système de demeurer dans un

équilibre permanent.
Tableau 2.2 Comparaison des trois solutions
(C1) (C2) (C3) (C4) (C5) (C6) Total

Phase 1 Moyen Fort Fort Fort Faible Moyen 21
Phase 2 Fort Moyen Fort Fort Faible Fort 22,5
Phase 3 Moyen Fort Fort Fort Fort Fort 25,5
0
La qualité de Evolutif Sécurité Scalabilité Performant Stabilité
service
Phase 1 Phase 2 Phase 3
Figure 2.7 Diagramme en bâton de comparaison des phases 1,2 et 3
Qualité de
service
5
4
3
Stabilité Evolutif
2
1
0
Performant Sécurité
Phase 1
Phase 2
Scalabilité Phase 3
Figure 2.8 Diagramme radar de comparaison entre les phases 1, 2 et 3
La solution technologique pour la gestion des configurations retenue est donc Le

DMVPN phase 3 qui l’emporte sur les autres avec un total de 25 points sur 30.
2.4.5. Le routage
Le routage [7] est le processus qu’un routeur utilise pour transmettre des paquets
vers un réseau de destination. Un routeur prend des décisions en fonction de l’adresse IP
de destination d’un paquet. Tout le long du chemin, les divers équipements se servent de
l’adresse IP de destination pour orienter le paquet dans la bonne direction afin qu’il arrive
à destination. Pour prendre les bonnes décisions, les routeurs doivent connaître la
direction à prendre jusqu’aux réseaux distants. Il existe deux types de routage à savoir :
- Le routage statique : Le routage statique est le fait de l’administrateur, les routes
manuellement dans la table de routage.
- Le routage dynamique : Routage effectué à l’aide d’un protocole de routage
dynamique qui remplit la table de routage du routeur et partage ses informations
avec les autres routeurs du réseau.
Dans la panoplie des protocoles de routage dynamique, chacun ayant son propre
caractéristique et son propre fonctionnement. Le tableau 2.3 [8, p. 15] Explique les
différents comportements des protocoles de routage dynamique lors lorsqu’ils
fonctionnent avec la technologie DMVPN.
Tableau 2.3 Comportement des protocoles rd routage face au DMVPN
Type de Annonce
topologie des Convergence CPU Scalabilité
routes
EIGRP Hub vers Spoke Bon Rapide Traitement Inférieur
Spoke vers Spoke élevé
OSPF Hub vers Spoke meilleur Rapide Traitement Inférieur
Spoke vers Spoke élevé
BGP Hub vers Spoke Bon Très lent Moyen Moyen
Spoke vers Spoke
RIPV2 Hub vers Spoke Médiocre Très lent Faible Elevé
Autres Hub vers Spoke Médiocre Très lent Faible Elevé
Tels sont les comportements des différents protocoles vis-à-vis de la solution DMVPN.
2.4.5.1. Choix du protocole de routage
Nous pouvons constater sur le tableau 2.3, seul les protocoles OSPF, EIGRP et
BGP permettent de faire du trafic Spoke vers le Spoke et Spoke vers Hub, ce qui ne donne
pas la chance aux autres pour être utilisé pour un réseau maillé complet ou partiel.
Comment alors départager ces 3 protocoles ?
La caractéristique la plus notable partagée par l’ensemble de ces protocoles

consiste pour un routeur à diffuser de façon périodique la totalité de sa table de
routage sur toutes ses interfaces qui participent au protocole. Le seul protocole
dérogeant à cette règle est EIGRP, protocole propriétaire de CISCO qui remplace IGRP.
En effet, les mises à jour d’EIGRP ne sont ni diffusées, ni générées de façon périodique
pas plus qu’elles ne contiennent l’entièreté de la table de routage.
Vous l’avez bien compris, nous avons jeté notre dévolu sur le protocole EIGRP
car en plus de la particularité présentée ci-haut, les mises à jour émises par un routeur
sont non périodiques, partielles, ciblées et fiables
 Non périodiques : les mises à jour sont événementielles, c’est-à-dire

qu’elles n’interviennent que lors d’un changement de métrique ou de
topologie.
 Partielles : les mises à jour ne contiennent que les routes qui ont changé
et non tout le contenu de la table de routage.
 Ciblées : les mises à jour envoyées à un voisin le sont parce que les
changements relatés par la mise à jour affectent ce voisin.
 Fiables : les mises à jour sont transportées à l’aide du protocole
RTP ( Reliable Transport Protocol), protocole conçu par CISCO et
qui garantit la remise, l’intégrité et le séquencement des paquets.
2.4.5.2. Optimisation du routage
Dans le routage classique, lorsque le réseau s’élargie, le processus de

routage consomme de plus en plus de ressource machines ce qui entraine des
performances médiocres. L’optimisation des performances d’un routeur est liée à
l’optimisation des opérations de recherche dans les différentes tables (routage et ARP).
Figure 2.0.9 Recherche récursive dans la table de routage
Le routage des paquets destinés à 172.16.1.1 se fait via l’interface Ethernet

0/1. On voit bien ici qu’il faut 3 recherches consécutives pour trouver le bon résultat.
Le DMVPN utilise service de mis en cache des informations sur les

différentes destinations déjà contacter. L’idée est la suivante: je viens de chercher une
information dans la table de routage, plutôt que de faire la même chose pour tous les
paquets qui vont suivre, pourquoi ne pas garder l’information dans une zone mémoire, un
cache en somme. Cet apport dans le processus de routage s’appelle CEF, pour Cisco
Express Forwarding. Cette technologie utilise deux concepts dont la RIB19 qui est la table
de routage ainsi que la FIB20 la base de données qui contient les informations mises en
cache. La commande « show ip cef » montre directement le contenu de la FIB.
Figure 2.10 Mémoire cache du CEF
La technologie CEF permet de rendre les informations plus facilement accessibles

sans besoins d’une recherche récursive dans la table de routage. Elle est une de ces
« nouvelles méthodes » de commutation (ou de routage). Avec CEF, il est effectivement
possible de commuter rapidement un paquet IP sur la base de l’adresse IP destination sans
avoir de besoin d’étiquette supplémentaire comme pour le VPN/MPLS pour gagner en
temps et en ressource.
2.5.Conception physique
2.5.1. Introduction
Les fournisseurs sont des entreprises offrant différents services, qui peuvent être
data en disponibilisant une architecture réseau bien montée ou la fourniture à l’accès à
Internet, à des entreprises et organisations en leur donnant accès à leur infrastructure de
communication tout en maintenant sécurité de transmission et qualité de service selon un
contrat de service appelé SLA21.
Un SLA est négocié entre l’opérateur et l’entreprise pour définir précisément les
droits de chacun et les performances attendues dans le VPN. La technologie des
équipements utilisés par le fournisseur n’est pas un problème pour le client tant l’accord
est respecté. Ainsi, dans notre travail, nous n’allons pas nous attarder sur la technologie
des matériels utilisés pour des liaisons intersites.
19
RIB : Routing Information Base, table de routage du CEF
20
FIB : Forwading Information Base, cache des information de routage
21
Service Level Agreement, accord sur la qualité de service offert par le fournisseur à un client
Néanmoins l’entreprise cliente doit être rassurée sur des points qui lui permettront
construire un réseau VPN robuste car la notion de qualité de service, ou QoS dans notre
cas, concerne certaines caractéristiques d’une connexion réseau relevant de la seule
responsabilité du fournisseur du service réseau.
Ces éléments sont tels que :
- Délai d’établissement de la connexion réseau : Correspond au temps qui

s’écoule entre une demande de connexion réseau et la confirmation de la
connexion. Ce paramètre de QoS indique le temps maximal acceptable par
l’utilisateur.
- Le débit de transit lors du transfert des données : Le temps de transit
correspond au temps écoulé entre une demande de transfert de données et
l’indication de transfert des données. Ce temps de transit est difficile à calculer du
fait de la distribution géographique des extrémités.
- Protection de la connexion réseau : Détermine la probabilité que la connexion
réseau soit en état de marche durant toute la période où elle est ouverte par
l’utilisateur. Il y a plusieurs moyens de protéger une connexion en la dupliquant
ou en ayant une connexion de sauvegarde prête à être ouverte en cas de coupure.
- Coût maximal acceptable : Détermine si la connexion réseau est tolérable ou
non. La définition du coût est assez complexe puisqu’elle dépend de l’utilisation
des ressources nécessaires à la mise en place, au maintien et à la libération de la
connexion réseau.
La Figure 2.11 illustre l’architecture physique notre système qui dépend en grande
partie du fournisseur avec lequel l’entreprise avoir un contrat comme nous l’avons déjà.
C’est ainsi que les antennes illustré sur la figure, le support de transmission sur le côté
WAN ainsi que le réseau public par lequel le fournisseur décide de faire passer le trafic
de ses clients dépend d’un fournisseur à un autre.
Figure 2.11 Architecture physique du système
2.5.2. Critère des matériels coté LAN
Un système ne naissant pas par le fait du hasard, la question du choix des

composants qui le constituent n’est pas anodine. Ce choix doit reposer sur des critères
objectifs et justifiables. Dans notre cas, nos critères de choix seront dictés par la solution
DMVPN qui exige certaines catégories des routeurs ainsi que certains IOS supportant
cette solution.
 Un routeur : le choix effectif des routeurs est fonction de la technologie
que nous présentons étant donné qu’il existe toute une panoplie des
routeurs pour des besoins différents.
Tableau 2.4 Liste des routeurs compatibles avec la solution
Id Modèle des routeurs

1 7200
2 3700
3 3600
4 1700
5 831
6 836
7 837
 Câble : Le standard Ethernet offre une grande variété catégories des câbles.
Pour notre cas, il n’y a pas de préférence dans le choix de câbles à paires
torsadés. Mais il recommandé d’utilisé les câbles à paires torsadés de
catégorie 3 ou 5 pour la compatibilité avec le PoE.
 Les racks : Baie dans lesquels sont rangés des périphériques empilés et
ainsi gagner de la place.
 PoE : Power over Ethernet, repose sur une norme qui fait de la
transmission du courant en même temps que des données. Les câbles
restent du RJ45 Catégorie 3 ou 5. Cet équipement est souvent utilisé un
pour alimenter un autre équipement qui n’est pas directement alimenté par
une tension électrique.
2.5. Conclusion partielle

Dans cette partie du travail, il était question de faire la conception générale
qui nous a permis de définir l’architecture générale du système, la conception logique
détaillée quant à elle, nous a permis de faire mener une étude et d’avoir une vue splendide
de certaines solutions existantes.
45
CHAPITRE 3 : IMPLEMENTATION DU SYSTEME
3.1. Introduction
Ce travail de fin d’étude est une solution de gestion des réseaux VPN IPSec en
évolution. Après bien sûr deux chapitres minutieusement traités pour donner une idée
précise à ce travail, ce troisième et dernier chapitre est consacré à l’implémentation de la
solution pour vérifier le développement fait dans les précédents chapitres. La simulation
sera faite par des moyens matériels et logiciels d’un ordinateur devant regrouper un
certain nombre d’exigences.
Comme dit ci-haut, ce chapitre sera purement pratique pour donner vie à notre
étude et celui-ci sera structuré en regroupant toutes les étapes pour la réalisation de
cette étude et c’est dans le but de permettre aux lecteurs passionnés par l’administration
réseau et plus précisément des réseaux privés virtuels en particulier de se sentir dans le
bain du sujet pour une mise en place ultérieure selon les brèches qu’ils rencontreront
dans le présent travail.
3.2. Simulation de la solution

3.2.1. Prérequis matériels
Avant la mise en place d’un projet informatique, il est toujours nécessaire
de réunir toutes les conditions tant matérielles que logicielles pour une avancée
sans jambages du projet.
 L’ordinateur doit avoir une mémoire vive ayant au moins une

capacité de 2Gb
 L’ordinateur doit avoir un microprocesseur qui supporte
l’émulation.
Ceci revient à dire que nous devons éviter des architectures trop robustes si nous
ne disposons pas d’une machine performante ou ayant peu de mémoire.
3.2.2. Prérequis logiciels

 Le simulateur GNS3
Le choix du logiciel Graphical Network Simulator pour cette mise en place est
très pratique pour représenter une maquette d’un réseau. GNS3 sert à reproduire une
architecture physique ou logique complète avant la mise en production.
 IOS Cisco
Ce système d’exploitation Cisco permet de connecter les réseaux et celui-ci doit
être téléchargé chez Cisco selon la série de notre matériel que nous désirons
interconnecter et pour le compte de notre simulation.
IMPLEMENTATION DU SYSTEME 46
Pour notre simulation, nous n’allons pas utiliser le routeur le moins couteux dans
la gamme des routeurs qui supporte la solution que nous avons comparé dans le deuxième
chapitre car il ne figure pas dans la catégorie des routeurs que le simulateur GNS3
propose. De ce fait nous allons utilisez le routeur Cisco 7200 que l’on retrouve dans la
gamme des routeurs que GNS3 propose. Sur ce routeur nous allons y mettre l’IOS Cisco
version 12.4.
Lors de la mise en place de notre étude, toutes les commandes que nous taperont
en interface de ligne de commande seront prises en charge par l’IOS et ce dernier utilise
deux espaces mémoires pour stocker sa configuration.
 La running-config est typiquement stockée en mémoire vive
(RAM) et qui contient la configuration actuellement utilisée ;
 La startup-config est typiquement stockée en mémoire non
volatile(NVRAM) et qui contient la configuration au démarrage du
matériel.
C’est pourquoi lors de la fin de configuration de l’IOS dans notre projet,
nous n’oublierons pas de copier la running-config à l’intérieur de la startup-config. Le
regroupement des éléments précités nous favorisera une bonne simulation de la solution
avant bien sûr la mise en production dans un réseau quelconque.
3.3. Mise en place de la simulation de la solution

3.3.1. Adressage réseau
Et notre topologie réseau d’études donne les détails de toutes les adresses IP des
interfaces des routeurs ainsi que des ordinateurs de simulation afin de comprendre
la façon dont l’acheminement du trafic se procèdera.
Tableau 3.0.1 adressage de la topologie implémentée
Id Equipement Plan de IP IP tunnel IP LAN

nommage Publique
192.168.10.0/24
1 R1 Hub 15.0.0.1/24 10.0.0.1/24 192.168.11.0/24
192.168.12.0/24
192.168.13.0/24
192.168.20.0/24
2 R2 Spoke_1 15.0.0.2/24 10.0.0.2/24 192.168.21.0/24
192.168.22.0/24
192.168.23.0/24
3 R3 Spoke_2 15.0.0.3/24 10.0.0.3/24 192.168.3.0/24
192.168.40.0/24
4 R4 Spoke_3 15.0.0.4/24 10.0.0.4/24 192.168.41.0/24

192.168.42.0/24
192.168.43.0/24
5 VPCS1 - - - 192.168.1.2/24
6 VPCS2 - - - 192.168.2.2/24
7 PC physique WINDOWS - - 192.168.3.2/24
8 VPCS4 - - - 192.168.4.2/24
3.3.2 Topologie implémentée pour notre étude

3.4 Planification et procédure

Dans la configuration de notre solution nous allons segmenter sa mise en place en
deux grandes catégories à savoir :
1. La mise en place du réseau VPN

2. L’application de la sécurité au réseau VPN
3.4.1 Mise en place des tunnels

3.4.1.1 Configuration du réseau Virtuel
Voici la liste de configuration qui permettra de mettre en place notre réseau virtuel sans
sécurité :
- La configuration des interfaces physiques des routeurs ;

- La configuration des interfaces de loopback ;
- La configuration du VPCS ;
- La configuration des tunnels sur le routeur Hub ainsi que sur les
routeurs Spoke ;
- La mise en place du routage entre les différents sites.
3.4.1.2. Test du réseau virtuel

Une fois les différentes configurations concourant à la mise en place du réseau
virtuel, nous procèderons au teste des différents composants qui permettront de vérifier
la bonne marche de notre solution. Nous utiliserons des outils tels que :
- La vérification de l’annonce des routes sur quelques routeurs ;

- La vérification de l’état des tunnels ;
- L’outil Ping ;
- L’outil traceroute.
A. Configuration de base
Avant d’entrer dans le fin fond de la configuration d’un réseau constitué des
routeurs, il faut mettre en place certaines configurations basiques entre autre : les adresses
IP des interfaces du routeur pour les interfaces WAN ou NBMA ainsi que les interfaces
de Loopback pour simuler des LAN.
Les interfaces fastEthernet 0/0 de R1, R2, R3 et R4 feront office des interfaces
WAN et trouvent dans un même réseau.
Pour une meilleure lisibilité des configurations, nous allons commencer à

renommer les différents routeurs du réseau selon leur fonction dans le réseau. Le routeur
R1 sera renommer logiquement comme Hub et les routeurs R2, R3 et R4 seront renommés
respectivement en Spoke_1, Spoke_2 et Spoke_3, étant des Spokes.
- L’interface fastEthernet 0/0 est l’interface du réseau publique ;

- L’interface fastEthernet 1/0 est l’interface d’un réseau local physique.
R1(config)#hostname Hub
Hub(config)#int fastEthernet 0/0
Hub(config-if)#ip address 15.0.0.1 255.255.255.0
Hub(config-if)#no shutdown
Hub(config)#int fastEthernet 1/0
Hub(config-if)#no shutdown
Figure 3.1 Configuration des interfaces physiques de R1
Cette configuration est faite sur le routeur R1 à travers l’interface de la ligne de

commande, la procédure est celle d’accéder premièrement à l’interface du routeur à
travers son ID est dans son exemple c’est à l’interface fastEthernet ayant comme ID 0/0 ;
et ensuite adresser cette interface avec son adresse IP suivi bien sûr du masque de sous
réseau en décimal et en fin activer cette interface qui par défaut est désactiver ; et ainsi
reprendre la même procédure pour la configuration de l’interface fastEthernet ayant
comme ID 1/0. Cette configuration est aussi valable pour les Spokes.
R2(config)#hostname Spoke_1
Spoke_1(config)#int fastEthernet 0/0
Spoke_1(config-if)#ip address 15.0.0.2 255.255.255.0
Spoke_1(config-if)#no shutdown
Figure 3.2 Configuration des interfaces de R2
Figure 3.4 Configuration des interfaces de R4

B. Configuration des interfaces de Loopback
Hub(config)#int loopback 0
Hub(config-if)#int loopback 1
Hub(config-if)#ip address
Figure 3.5 Configuration des interfaces de loopback du Hub

52
B. Configuration des VPCS
Les VPCS22 sont des simulateurs des machines virtuelles qui seront connectés sur
les commutateurs connectés au routeur R3 afin d’effectuer le test de connectivité entre
différents réseau. La configuration des VPCS consiste à renseigner l’adresse IP de la carte
réseau de la machine ainsi que la passerelle de ce réseau en accédant à la console de
VPCS. La commande save permet de sauvegarder les configurations de la machine
virtuelle. Elle prend en paramètre le nom du fichier qui contiendra les configurations,
pour notre cas le nom est « startup.vpc ».
PC1>ip 192.168.3.2/24 192.168.3.1

PC1>save startup.vpc
Figure 3.6 Configuration du VPCS

Une fois ces configurations basiques effectuées, nous passons directement à la
configuration du Hub en créant l’interface tunnel nommé « Tunnel 0 » pour le NHRP
dont voici la procédure de configuration détaillé dans le tableau …..
C. Configurations des tunnels

 Configuration du routeur Hub
Nous procédons d’abord à la configuration du routeur Hub
Tableau 3.0.2 Procédure configuration du routeur Hub
Commande But de la commande

Etape 1 interface tunnel 0 Création du tunnel
Etape 2 ip address <adresse ip> <masque Détermination de l’adresse du tunnel
de sous réseau>
Etape 3 ip nhrp authentication <Mot de Configuration d’un mot de passe pour
passe> tous les échanges NHRP ce qui offre
une sécurité basique.
N.B. : Le mot de passe doit être le
même sur le(s) Hub et les Spokes
Etape 4 ip nhrp multicast dynamic Configure le NBMA en multicast et
apprend dynamiquement les
destinations.
22
Simulateur des machines virtuelles intégré à GNS3
Etape 5 ip nhrp network-id <numéro> Détermination de l’identifiant du

réseau DMVPN. Cet argument est un
nombre qui peut varier entre 1 et
4294967295.
Etape 6 tunnel source <adresse ip / Spécifie le tunnel source
interface>
Etape 7 tunnel mode gre multipoint Un tunnel GRE multipoint
Etape 8 ip nhrp redirect Rédirige une demande pour permettre
aux Spoke de commencer à répondre
aux requêtes.
Hub(config)#interface Tunnel0
Hub(config-if)#ip nhrp authentication DMVPN
Hub(config-if)#ip nhrp map multicast dynamic
Hub(config-if)#ip nhrp network-id 1
Hub(config-if)#tunnel source fastEthernet0/0
 Configuration d’un Spoke
Hub(config-if)#tunnel mode gre multipoint
Hub(config-if)#ip nhrp redirect
Figure 3.7 Configuration du tunnel sur le Hub

 Configuration d’un Spoke
Il faut noter que ces configurations sont valables sur tous les routeurs et à travers
toutes les interfaces connectées aux routeurs. Nous allons simplement mettre la
configuration du Spoke_1 et les informations qui changeront pour les autres Spokes
seront leurs adresses ip publique de l’interface WAN, pour Spoke_2 qui sera 15.0.0.3 et
pour Spoke_3 qui sera 15.0.0.4, ainsi que les adresses de leurs tunnels respectifs, 10.0.0.3
pour Spoke_2 et 10.0.0.4 pour Spoke_3. Le tableau 3.3 et la figure 3.8 illustrent la
configuration du Spoke_1.
Tableau 3.0.3 Procédure de configuration d'un Spoke

Etape 1 interface tunnel 0 Création du tunnel
Etape 2 ip address <adresse ip> <masque Détermination de l’adresse du tunnel
de sous réseau>
Etape 3 ip nhrp authentication <Mot de Configuration d’un mot de passe pour

passe> tous les échanges NHRP ce qui offre
une sécurité basique.
N.B. : Le mot de passe doit être le
même sur le(s) Hub et les Spokes.
Etape 4 ip nhrp map multicast <adresse Les paquets multicast seront envoyés
ip publique du serveur Hub> via tunnel GRE au serveur Hub.
Etape 5 ip nhrp map <adresse ip privée du Le mappage de l’adresse ip privée
Hub> <adresse ip publique du (adresse du tunnel) avec l’adresse ip
Hub> publique du Hub (adresse de
l’interface WAN).
Etape 6 ip nhrp network-id <numéro> Détermination de l’identifiant du
réseau DMVPN. Cet argument est un
nombre qui peut varier entre 1 et
4294967295.
Etape 7 ip nhrp nhs <adresse du tunnel du Détermination du Next-hop Server
Hub> (NHS)
Etape 8 tunnel source <adresse ip / Spécifie le tunnel source
interface>
Etape 9 tunnel mode gre multipoint Un tunnel GRE multipoint
Etape 10 ip nhrp shortcut Permet aux Spokes de commencer
aussi à répondre aux requêtes.
Spoke_1(config)#interface Tunnel0
Spoke_1(config-if)#ip nhrp authentication DMVPN
Spoke_1(config-if)#ip nhrp map 10.0.0.1 15.0.0.1
Spoke_1(config-if)#ip nhrp map multicast 15.0.0.1
Spoke_1(config-if)#ip nhrp network-id 1
Spoke_1(config-if)#ip nhrp nhs 10.0.0.1
Spoke_1(config-if)#tunnel source fastEthernet0/0
Spoke_1(config-if)#tunnel mode gre multipoint
Spoke_1(config-if)#ip nhrp shortcut
Figure 3.8 Configuration du tunnel sur le Spoke_1

Nous pouvons constater, qu’à l’exception de l’adressage, la configuration est

similaire pour tous les Spokes. Ce qui montre à quel point un nouveau venant s’intégrer
à la topologie DMVPN existant peut être facilement intégré. Avant de pouvoir passer à
un éventuel test de notre système, il faut mettre en place le routage entre les routeurs du
réseau.
D. Le routage entre sites
Jusque-là il n’y a aucune connectivité entre les différents LAN des différents
routeurs. Le protocole de routage dynamique EIGRP, que nous avons choisi pour notre
travail, va pouvoir nous aider à propager les routes des LAN de chaque routeur respectif
et de le partager à travers les tunnels établis sur le réseau public. Notons une fois de plus
que la configuration qui suit s’applique encore une fois de façon similaire sur l’ensemble
des routeurs du réseau, sauf les adresses réseaux des LAN qui commenceront à changer.
Tableau 3.0.4 Procédure de configuration du protocole de routage EIGRP

Etape 1 router eigrp <Numéro AS> Activation du processus EIGRP
network <adresse réseau> <masque Annonce d’un réseau
Etape 2 générique>
Etape 3 no ip split-horizon eigrp <Numéro Désactivation du partage d’horizon.
AS>
Hub(config)#router eigrp 5
Hub(config-router)#network 10.0.0.0 0.0.0.255
Hub(config-router)#no auto-summary
Hub(config-router)#passive-interface fastEthernet 1/0
Hub(config-router)#interface tunnel 0
Hub(config-if)#no ip split-horizon eigrp 5
Figure 3.9 Configuration du protocole routage EIGRP

Cette opération doit être faite sur tous les routeurs en renseignant leurs réseaux
respectifs.
3.4.2 Plan de teste
Nous voilà devant notre système qui prend déjà corps, nous allons procéder au
premier test. Nous allons procéder de la manière qui suit :
- Vérifier l’annonce des routes par le protocole de routage ;
- Vérifier l’état des tunnels entre les routeurs ;
- Tester la connectivité entre LAN.
Le respect des paramètres de sécurité est de rigueur pour l’effectivité du réseau

virtuel car, si elle n’est pas la même partout, il y’aura aucune communication entre les
routeurs du réseau. De ce fait nous procéderons à un deuxième test de connectivité une
fois notre politique de sécurité mis en place.
3.4.1.3. Vérification de l’annonce des routes
Figure 3.10 Annonce des routes
Tout marche comme sur des roulettes comme on peut le constater. En jetant un
coup d’œil dans la table de routage de routeur Hub, celle-ci est remplie de beaucoup de
routes des tous les Spokes, apprises dynamiquement par le protocole de routage
dynamique EIGRP via le tunnel, cela se justifie par la lettre D devant les routes des
routeurs distants.
3.4.1.4. Vérification des tunnels

S’agissant de la communication entre les sites via les tunnels, nous allons
procéder à la vérification de l’état des tunnels sur les différents routeurs du réseau. La
commande qui permet de vérifier cela est show dmvpn
Figure 3.11 Vérification des tunnels sur le Hub
Figure 3.12 Tunnel des tunnels sur le Spoke_3
Le routeur Hub possède 3 tunnels dynamiques montés pour chaque Spokes du

réseau. Ces tunnels servent à maintenir une communication permanente entre le serveur
Hub (NHS) avec les clients (NHC) pour différentes requêtes NHRP ainsi l’annonce des
mises à jours.
Le Spoke_3 possède un tunnel statique monté avec le routeur Hub pour la

synchronisation avec ce dernier.
3.4.1.5. Test de connectivité

Jusque-là tout se passe très bien, de ce fait nous allons procéder notre premier
test de connectivité entre la machine virtuelle VPCS2 se trouvant dans le réseau
192.168.2.0/24 du Spoke_1 avec le VPCS3 dans le réseau 192.168.3.0/24 du Spoke_2.
Figure 3.13 Test de connectivité
Vérifions maintenant l’état des tunnels sur le Spoke_1
Figure 3.14 Tunnel dynamique entre Spoke_2 et Spoke_3
Vérifions également l’état des tunnels sur le Spoke_2
Figure 3.15 Tunnel dynamique entre Spoke_3 et Spoke_2
Nous allons également nous servir de la commande traceroute pour vérifier les sauts
empreintés par le trafic dans le réseau. Nous simuler un trafic quittant le Spoke_2 vers le
VPCS du Spoke _4.
Figure 3.16 Vérification des sauts empruntés par un trafic
Après avoir testé la connectivité, nous pouvons constater que le premier saut par
lequel passe le trafic est l’interface du tunnel du Spoke_2 et non celle du routeur Hub, ce
qui confirme la création du tunnel dynamique ou raccourcis entre le routeur Spoke_2 et
le routeur Spoke_3.
2.4.1.6. Agrégation des routes

Etant donné que dans notre réseau, les Spokes n’ont pas besoin d’une entrée
spécifique pour contacter une éventuelle destination, grâce au protocole NHRP, dans ce
cas nous allons alléger les tables de routages des Spokes en agrégeant les routes des mises
à jour en une route par défaut.
Une route par défaut est toute indiquée quand un routeur est utilisé pour
connecter un réseau local au reste du monde. En effet, dans ce cas, toute requête émise
par l’un des hôtes du réseau local, réseau situé derrière le Hub tout comme les Spokes, et
destinée au reste du monde doit transiter par ce chemin.
La syntaxe est : ip summary-address eigrp <numéro-as> <adresse réseau> <subnet-

mask>
Hub(config)#interface tunnel 0
Hub(config-if)#ip summary-address eigrp 5 0.0.0.0
0.0.0.0
Figure 3.17 Agrégation des routes en une route par défaut

Figure 3.18 Table de routage de Spoke_1 après agrégation des routes
Ainsi, seul le Hub possèdent sa table de routage bien remplie et celle des Spokes
devient sensiblement allégé comme le montre la figure 3.18. De ce fait les Spokes n’ont
pas besoin de suivre l’évolution du réseau. Ainsi on peut construire un réseau à moindre
coût sans avoir besoin de posséder des routeurs de grandes performances aux niveaux des
succursales, de ce fait les routeurs des succursales pourront suivre l’évolution du réseau
sans avoir des grandes capacités comme le routeur du siège central.
3.4.2 Mise en place de la Sécurité

Nous avons surement remarqué pour le moment que nous n’avons pas implémenté
aucun mécanisme de sécurité. Autrement dit à ce stade tout le trafic transitant par le réseau
public est en clair. De ce fait il faudra mettre en place une politique de sécurité IPSec. Il
est impérativement à noter que la dite politique devra être respecté sur tous les routeurs
du réseau.
3.4.2.1 Etapes de la configuration d’une politique IPSec

 Création de la politique de sécurité
La politique de sécurité porte un identifiant et permet de définir la manière dont
les clés seront apprises. Le numéro du profile que nous allons utiliser est « 10 »
Syntaxe : crypto isakmp policy <ID>
Authentification pre-shared
 Configuration de la clé ISAKMP

ISAKMP est en soit un cadre qui permet de définir les mécanismes de sécurité
ainsi que la négociation d’une politique de sécurité. La clé ISAKMP est juste une chaine
de caractère que l’on peut nommer à volonté. La clé secrète que nous allons utiliser dans
ce travail est « ClefSec »
Utilisé l’adresse IP publique et son masque afin de préciser la route pour la

création dynamique du tunnel IPSec. Dans notre cas c’est la route par défaut 0/0 ou 0.0.0.0
0.0.0.0
Syntaxe : crypto isakmp key <clefsecret> adresse <adresse_réseau>

<masque_réseau>
 Configuration de la transformation IPSec

Une transformation IPSec décrit un protocole de sécurité avec ses algorithmes
correspondants. Le nom de la transformation est également une chaine de caractère sans
espace que l’on peut nommer à volonté. Pour ce travail le nom de la transformation est
« TransIPSec ».
Syntaxe : crypto ipsec transform-set <nom_de_la_transformation>
<transformation1> <transformation2>
 Création du profile IPSec
Le profile est le mécanisme qui permettra de sécurisé le tunnel GRE. Lors de sa
création, il contiendra le nom de la transformation IPSec. Le nom du profile IPSec est
aussi une chaine de caractère sans espace qu’on peut nommer à volonté. Pour notre travail
le nom est « ProfIPSec »
Syntaxe : crypto ipsec profile <nom_du_profile>
 Application du profile au tunnel
Syntaxe : tunnel protection ipsec profile <nom_du_profile>
Hub(config)#crypto isakmp policy 10

Hub(config-isakmp)#authentication pre-share
Hub(config-isakmp)#crypto isakmp key ClefSec address
0.0.0.0 0.0.0.0
Hub(config)#crypto ipsec transform-set TransIPSec esp-aes
esp-sha-hmac
Hub(cfg-crypto-trans)#crypto ipsec profile ProfIPSec
Hub(config-profile)#exit
Hub(config)#interface tunnel 0
Hub(config-if)#tunnel protection ipsec profile ProfIPSec
Figure 3.19 Configuration du protocole ISAKMP
Une fois la configuration finie, pour vérifier nous allons tenter de relancer un test
de connectivité entre le Spoke_1 avec le routeur Spoke_2
Figure 3.20 Test de connectivité
C’est bon signe, le test de connectivité passe sans problème. Voyons maintenant qu’est-
ce qui se passe du côté IPSec.
La commande show crypto isakmp sa
Figure 3.21 Etat des tunnels IPSec
Nous pouvons constater directement, sur le routeur Hub, que nous avons trois
connections IPSec déjà actives. Ce sont les tunnels dynamiques entre le routeur Hub et
les routeurs Spokes qui s’est négociées à l’activation des paramètres IPSec.
3.5 Conclusion partielle

Nous voilà à la fin de cette belle aventure dans le monde réseaux VPN IPSec, une
petite évaluation en termes de pourcentage sur le point de satisfaction des différents
besoins qui ont soutenu notre travail depuis le début. Le système est effectivement
fonctionnel et répond en grande partie aux exigences que nous nous assignés.
Le système est loin d’être parfait car tous les besoins n’ont pas été satisfaits à 100
%, il réalise qu’une moyenne de 86.06 % de satisfaction des besoins, ainsi des
améliorations peuvent toujours être faites pour toujours le rendre meilleur.
3.5.1 Evaluation des besoins

Tableau 3.0.5 Evaluation des besoins
Id Nom du besoin Evaluation Commentaire

B-01 QOS 80 % Le système optimise
l’utilisation de la bande
passante dans la circulation
du trafic sur le réseau.
B-02 Evolutivité 100 % Le système présente une

capacité à s’élargir sans
problème.
B-03 Sécurité 80 % Le système assure une
sécurité renforcé grâce aux
différents paramètres NHRP
ainsi que IPSec.
B-04 Scalabilité 90 % Le système d’adaptent
facilement à tout changement
d’évolutivité et peut
facilement être agrandi par
l’ajout des nœuds
supplémentaires.
B-05 Performance 80 % Le système assure un temps
d’attente raisonnable. Bref
globalement il répond bien
aux exigences.
B-06 Stabilité 90 % Le système présente une
capacité à demeurer dans un
équilibre permanent.
TOTAL - 86,66 % -
64
CONCLUSION GENERALE
Notre travail est arrivé à son terme. Il a été un voyage fabuleux dans les réseaux
privés virtuels. Il a traité essentiellement sur la gestion dynamique d’un réseau VPN IPSec
en croissance. Nous avons débuté par la présentation d’une mise en place simple et
classique d’une configuration réseau VPN et delà ce sont dégagés les besoins qui nous
ont permis de nous lancer sans aucun aménagement. Nous avons pu démontrer à quel
point il est fastidieux de faire croître un réseau VPN IPSec statique et ainsi en dégagés
les bases sur lesquelles devaient être menés des recherches dans le but de présenter une
solution facile à implémenter et évolutive.
Cette recherche associé à une étude, au-delà de nous apprendre de nouvelles

connaissances sur le plan personnel, nous a permis de comprendre toutes les briques
fondamentales qui composées notre système. Ainsi, sur base de critères et surtout des
besoins que nous avons définis, nous avons été de choisir les matériels et les logiciels les
plus appropriés pour les objectifs que nous poursuivions. La solution DMVPN phase 3
était celle qui répondait le mieux aux exigences que nous avons posés comme base dans
le choix d’une solution évolutive et économique.
Puis finalement nous sommes passés à l’étape complexe de l’implémentation de

la solution DMVPN phase 3. Pour nous en sortir, nous avons dû établir des procédures
précises et détaillées. Le travail d’implémentation n’en a été que facilité, à notre grande
satisfaction.
PERSPECTIVES D’AVENIR
En aucun cas nous prétendrons une éventuelle exhaustivité pour ce travail. Ainsi,
bien que présentant une base assez solide et intéressante dans la mise en place des réseaux
VPN IPSec, notre travail souffre de certaines limitations.
Nous n’avons donc pas pu étudier la possibilité de rendre le système hautement

disponible en mettant en place un routeur Hub de secours en cas d’indisponibilité du Hub
principale. A par le problème de la haute disponibilité du réseau, il y a également la mise
en place d’un serveur certificat pour la gestion de la sécurité d’une manière dynamique.
On peut donc déceler, dans les éléments cités ci-haut, des perspectives d’avenir
qui pourrait inspirer des travaux ultérieures.
En définitive donc, le système que nous avons conçu est tout à fait améliorable
sur divers plan et des vues très diversifiées.
65
REFERENCES
[1] O. S. e. J. N. Guy Pujolle, Les réseaux, Paris: EYROLLES, 2008.
[2] S. M. e. A. W. Dave Hucaby, Cisco Router Configuration Handbook,

Indianapolis: IT-Ebook, 2010.
[3] G. Pujolle, Les réseaux 5ème édition, Paris: EYROLLES, 2004.
[4] D. R. Christophe Perroud, «FIBER/LTE,» Hes so Fribourg Freiburg,

westschweiz, 2015.
[5] B. MARTIN, «IPSec : Techniques,» Fiche Technique, Paris, 2006.
[6] R. Dumont, «Cryptographie et Sécurité informatique,» Université de Liège -

Notes de cours, Liège, 2009 - 2010.
[7] [En ligne]. Available:

http://www.nyuplanet.eu/ccna/semestre4/course/module7/7.2.1.1/7.2.1.1.html.
[8] B. DAVENEL, «Les VPN MPLS,» Universit´e Paris-Est Marne la Vallée, Paris,
2000.
[9] M. Sullenberger, Advanced Concepts of DMVPN (Dynamic Multipoint VPN),

Ciscolive BRKSEC-4054, 2015.
[10] [En ligne]. Available:

https://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_addr/configuration/guide/had
nhrp.html.
[11] A. VAUCAMPS, CISCO Protocoles et concepts de routage -Configuration

avancée des routeurs, Editions ENI .
[12] Cisco IOS DMVPN Overview, Cisco Systems, 2008.

Langue

Etude155222555 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Etude155222555 PDF

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA

République Démocratique du Congo

Étude d’une mise en place d’une solution de

Travail présenté et défendu en vue de l’obtention

Par KASONGO SWANA Laure

Directeur : Bertin MPOLOMBWE

Co-Directeur : Daril SHINGALETA

Option : G3 Administration systèmes et réseaux

« L’intégrité est une composante essentielle de la sécurité. Et pas

A notre chère mère ILUNGA TSHIKWAKWA ;

A notre cher Oncle ILUNGA KANZA ;

A notre chère Tante Ernestine KAYEYE ;

Nous commençons premièrement par remercier respectivement notre directeur

Nos remerciements les plus sincères s’adressent également aux autorités

Le dernier merci ira à nos chères collègues de promotions : Jonathan NKUNGA,

Laure KASONGO SWANA

LISTE DES FIGURES

Figure 1.1 VPN d'accès .................................................................................................... 8

Figure 3.9 Configuration du protocole routage EIGRP................................................. 55

LISTE DES TABLEAUX

Tableau 1.1 Définition des exigences du futur système .................................................. 23

LISTE DES ACRONYMES

AES Advanced Encryption Standard

ARP Address Resolution Protocol

CEF Cisco Express Forward

DES Data Encryption Standard

DHCP Dynamic Host Control Protocol

DMVPN Dynamic Mutlipoint Virtual Private Network

EIGRP Enhanced Interior Gateway Routing Protocol

ESP Encryption Service Payload

GNS3 Graphic Network Simulator 3

GRE Generic routing protocol

IOS Internetworking Operating System

IPSEC Internet Protocol Security

IPX Inter-network Package eXchange

ISAKMP Internet Security Association Key

L2F Layer 2 Forwarding

L2TP Layer 2 Tunnel Protocol

MD5 Message Digest 5

MPLS Multi Protocol Label Switching

NAT Network Address Translation

NBMA Non Broadcast Multi Access

NHC Next-Hop Client

NHRP Next-Hop Resolution Protocol

NHS Next-Hop Server

OSPF Open Shortest Path First

PPP Point to Ponit Protocol

PPTP Point to Point Tunneling Protocol

QOS Quality Of Service

RFC Request For Comment

RIP Routing Interior Protocol

VPCS Virtual Private Computer Similator

VPN Virtual Prtivate Network

WAN Wide Area Network

3DES 3 Data Encryption Standard

TABLE DES MATIERES

3.2. Simulation de la solution .................................................................................. 45

L’Ecole Supérieure d’Informatique Salama régie par le programme national des

Toute entreprise, petite ou grande soit-elle, est appelée toujours à grandir et à

De même lors de la mise en place d’un réseau privé virtuel, penser à

Dans le présent travail, nous proposons une solution de déploiement d’un