Étude d’une mise en place d’une solution de déploiement d ... · Figure 1.5 Protocole AH avec ses algorithmes ... Figure 1.15 Configuration du tunnel VPN sur R1 ... Il est très

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

http://www.esisalama.org/

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.

http://ccie.julienberton.fr/2012/10/17/dmvpn-les-tunnels-a-la-demande/


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

PPP7, qui est le protocole majeur des VPN de niveau deux, c’est pourquoi nous allons

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.

http://www.frameip.com/toip/


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

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

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


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.

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

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


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

Business

Exigences Fonctionnelles et

non fonctionnelles

Exigence techniques

1 Interconnexion

des sites distants à

moindre coût

- Mise en place facile des

réseaux privés virtuels entre

sites distants ;

- Evolutif

- Sécurité assurée ;

- Scalabilité14 ;

- Performant

- Stabilité.

- Choix d’une solution

VPN qui permettra

même un choix

stratégique des

routeurs pour un

réseau évolutif

2 Assurer la qualité

de service

- Economique (en termes de

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

Protocol, Un protocole de

tunneling

Ce protocole de tunneling

utilisé pour encapsulé une

grande variété d’autres

protocoles tels que IP ou IPX.

2 IPSEC IP Security, protocole

utilisé

Ce protocole est utilisé pour

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

Protocol, est un protocole

de résolution de saut suivant

ou bond suivant.

C’est le protocole utilisé pour

déterminer le prochain saut

sur le réseau public. NHRP est

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

statique soit le

routage

dynamique

Le routage est le processus

qu’un routeur utilise pour

transmettre des paquets vers

un réseau de destination.

L’annonce des différentes

routes des différents LAN

interconnectés.

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


Figure 2.7 Diagramme en bâton de comparaison des 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.

0

1

2

3

4

5

6

La qualité deservice

Evolutif Sécurité Scalabilité Performant Stabilité

Phase 1 Phase 2 Phase 3

0

1

2

3

4

5

Qualité de

service

Evolutif

Sécurité

Scalabilité

Performant

Stabilité

Phase 1Phase 2Phase 3

Figure 2.8 Diagramme radar de comparaison entre les phases 1, 2 et 3


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

topologie

Annonce

des

routes

Convergence

CPU

Scalabilité

EIGRP Hub vers Spoke

Spoke vers Spoke

Bon Rapide Traitement

élevé

Inférieur

OSPF Hub vers Spoke

Spoke vers Spoke

meilleur Rapide Traitement

élevé

Inférieur

BGP Hub vers Spoke

Spoke vers Spoke

Bon Très lent Moyen Moyen

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

nommage

IP

Publique

IP tunnel IP LAN

1

R1

Hub

15.0.0.1/24

10.0.0.1/24

192.168.10.0/24

192.168.11.0/24

192.168.12.0/24

192.168.13.0/24

2

R2

Spoke_1

15.0.0.2/24

10.0.0.2/24

192.168.20.0/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.

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.

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

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.1 Configuration des interfaces physiques de R1

Figure 3.2 Configuration des interfaces de R2


B

B. Configuration des interfaces de Loopback








Hub(config)#int loopback 0


Hub(config-if)#int loopback 1





Hub(config-if)#ip address

Figure 3.4 Configuration des interfaces de R4

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

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

de sous réseau>

Détermination de l’adresse du tunnel

Etape 3 ip nhrp authentication <Mot de

passe>

Configuration d’un mot de passe pour

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

PC1>ip 192.168.3.2/24 192.168.3.1

PC1>save startup.vpc

Figure 3.6 Configuration du VPCS


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 /

interface>

Spécifie le tunnel source

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.

Configuration d’un Spoke

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

de sous réseau>

Détermination de l’adresse du tunnel

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

Hub(config-if)#tunnel mode gre multipoint

Hub(config-if)#ip nhrp redirect

Figure 3.7 Configuration du tunnel sur le Hub


Etape 3 ip nhrp authentication <Mot de

passe>

Configuration d’un mot de passe pour

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

ip publique du serveur Hub>

Les paquets multicast seront envoyés

via tunnel GRE au serveur Hub.

Etape 5 ip nhrp map <adresse ip privée du

Hub> <adresse ip publique du

Hub>

Le mappage de l’adresse ip privée

(adresse du tunnel) avec l’adresse ip

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

Hub>

Détermination du Next-hop Server

(NHS)

Etape 8 tunnel source <adresse ip /

interface>

Spécifie le tunnel source

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

Etape 2

network <adresse réseau> <masque

générique>

Annonce d’un réseau

Etape 3 no ip split-horizon eigrp <Numéro

AS>

Désactivation du partage d’horizon.

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>

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

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


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.

Documents

Étude d’une mise en place d’une solution de déploiement d ... · Figure 1.5 Protocole AH avec ses algorithmes ... Figure 1.15 Configuration du tunnel VPN sur R1 ... Il est très