IV.5.2.3 Fonctionnement d'IPec
Pour configurer le protocole IPSec on a besoin de configurer les
éléments suivants :
· Créer l'IPSec Transform.
· Créer une ACL étendue.
· Créer le crypto map.
· Appliquer crypto map à l'interface publique
Cette étape consiste à créer la
transformation définie utilisée pour protéger les
données
(IPSec) nommé `'vpntrans».
Figure IV- 33: Configurations
d'IPsec
L'ACL étendu que l'on crée permettra de
définir le trafic qui passera à travers le tunnel VPN. Dans notre
projet, le trafic s'achemine du réseau 10.0.0.0/24 à
192.168.5.0/24.
[103]
R2(config)#access-list 100 permit ip 192.168.4.0 0.0.0.255
192.168.5.0 0.0.0.255
Chapitre IV Sécuriser un réseau bancaire avec la
blockchain
La crypto map est la dernière étape
d'installation et d'établissement du lien entre ISAKMP définie
précédemment et la configuration IPSEC :
Figure IV- 34: Configuration de la crypto
map
Maintenant il suffit d'appliquer la crypto map sur l'interface
de sortie de routeur :
Figure IV- 35: Application de la crypto
map
Dès que nous appliquons crypto map sur l'interface,
nous recevons un message de Router qui confirme ISAKMP : ISAKMP is ON.
Les paramètres pour le routeur R1 sont identiques, la
seule différence étant les adresses IP attribuées et les
listes d'accès.
IV.5.2.4 Test de Protocol IPsec
À ce stade, nous avons terminé notre
configuration et le tunnel VPN est prêt à être mis en place.
Pour lancer le tunnel VPN, nous devons forcer un paquet à traverser le
VPN et cela peut être réalisé en envoyant un ping d'un
routeur à un autre.
Pour tester le VPN, on fait un ping entre les deux hôtes
distants. Puis sur le routeur rattaché à la machine qui a
effectué le ping, tapez la commande (show crypto isakmp
sa) et on aura des informations sur la source et la distance.
Chapitre IV Sécuriser un réseau bancaire avec la
blockchain
[104]
Figure IV- 36: Vérification des
opérations d'ISAKMP
Et pour confirmer, on va voir les paquets encapsulés et
autres en tapant (show crypto ipsec sa).
Figure IV- 37: Encapsulation des
données
Cela prouve que le tunnel à bien été mis
en place mais la communication entre les deux sites n'est pas
sécurisée.
Problème 5 : pourquoi la communication n'est pas
sécurisée malgré que le tunnel soit bien placé ?
Solution 01 : vérification si le crypto sur les
interfaces du sortir de paquets est bien appliqué !
Figure IV- 38: Vérification de la crypto
map
§ Les paramètres de cryptages sont bien
appliqués
o Notez que vous ne pouvez affecter qu'un seul crypto map
à une interface.
Solution 02 : vérifier la liste d'accès ACL
Chapitre IV Sécuriser un réseau bancaire avec la
blockchain
[105]
Figure IV- 39: Vérification de la liste
d'accès
Il y a un problème sur la création de la liste
d'accès pour sécuriser le réseau 192.168.4.0 du routeur et
non pas le réseau où se trouve le serveur banque 10.0.0.0.
Maintenant, on va juste créer une nouvelle liste d'accès
permettant de crypter le réseau du serveur.
R2(config)#access-list 100 permit ip 10.0.0.0 0.255.255.255
192.168.5.0 0.0.0.255
Maintenant, il devrait être allumé on refait le
test.
Figure IV- 40: Vérification d'IPsec
sa
Maintenant, rappelez vous que le FAI n'a pas une idée
sur les deux réseaux pourtant le ping marche bien. Avec le packet
tracer, nous rentrons dans le mode de simulation. On laisse que le filtre ICMP,
puis on va mettre en place un packet sur le serveur bank et puis un autre sur
le serveur client et on capture et on observe le packet qui traverse les
routeurs. Quand le packet arrive au FAI, on regarde à l'intérieur
du packet.
Chapitre IV Sécuriser un réseau bancaire avec la
blockchain
[106]
Figure IV- 41: Information du PDU sur
R0(FAI)
Le FAI préocupe par le fait que le packet vient de la
source IP 192.168.2.101 et avec une déstination 192.168.1.101 grace
à l'en-tete ESP qui va crypter les données et les envoyer sur le
tunnel .
Voici la réel source :
Figure IV- 42: Information du PDU non crypté
En fin, on a obtenu le meuilleur résultat .
Chapitre IV Sécuriser un réseau bancaire avec la
blockchain
[107]
Figure IV- 43: Teste de la topologie
Avec un ping manuel maintenant
Figure IV- 44: Test de la topologie
manuellement
Pour la confirmation, on tape la commande sh crytpo
ipsec sa, qui nous retourne le résultat suivant :
Figure IV- 45: Confirmation de cryptage et
décryptage de données
Le réseau fonctionne comme prévu. La source de
trafic du R2 vers les destinations Internet est traduite avec un
mécanisme IPsec tandis que le trafic provenant du R4 vers le R3 n'est
pas traduit. Cependant, ce trafic doit être protégé lors de
l'échange de la monnaie. Donc, notre but est de protéger le
trafic qui passe entre bank et amazon.
Chapitre IV Sécuriser un réseau bancaire avec la
blockchain
Problème 06 : comment protéger le trafic entre la
bank et amazon ?
Solution 01 dans ce scénario, on propose de
créer un tunnel GRE entre R4 et R3
IV.6 Implémentation d'in GRE tunnel
IV.6.2 Introduction
Tunneling fournit un mécanisme pour le transport de
paquets d'un protocole à l'intérieur d'un autre protocole. Le
protocole qui est transporté est appelé protocole passager, et le
protocole qui est utilisé pour transporter le protocole passager est
appelé protocole de transport. Generic Routing Encapsulation (GRE) est
un des mécanismes de tunneling qu'utilise IP comme protocole de
transport et il peut être utilisé pour transporter
différents protocoles. Les tunnels se comportent comme des liens point
à point virtuels qui ont deux extrémités
identifiées comme tunnel source et tunnel destination.
Le diagramme suivant montre le processus d'encapsulation d'un
paquet GRE quand il croise le routeur et rentre dans le tunnel d'interface :
Figure IV- 46: Fonctionnement du Tunnel
GRE
Pour notre configuration, on a utilisé bien la
topologie en capture d'écran suivante :
Figure IV- 47: Insertion du Tunnel
GRE
[108]
| 
