Lorsque vous avez deux LAN à interconnecter, la mise en place d’un VPN GRE avec ou sans IPsec, ou un VPN IPsec classique, c’est-à-dire une liaison point à point, peut suffire. Cependant, si vous devez interconnecter plusieurs LAN, utiliser des tunnels point à point devient vite fastidieux, c’est là que le DMVPN nous sera utile.
Une des solutions idéales est de créer un tunnel avec plusieurs points d’entrée et de sortie, appelé Dynamic Multipoint VPN (DMVPN). Notons ici que DMVPN est une technologie propriétaire de Cisco, et à ce titre, elle est principalement disponible sur les équipements Cisco. Cependant, certains concepts et technologies utilisés par DMVPN, tels que mGRE (Multipoint GRE), NHRP (Next Hop Resolution Protocol), et IPsec, sont standards et peuvent être implémentés sur d’autres plateformes.
Cette technologie permet de créer des tunnels entre plusieurs sites à la demande, c’est-à-dire lorsque le trafic d’un LAN doit être acheminé vers un autre LAN.
Composants Clés du DMVPN
mGRE (Multipoint GRE) :
Le mGRE fonctionne de manière similaire au GRE, mais au lieu d’être point à point, il est multipoint, structuré en architecture Hub & Spoke. Le Hub est connecté à plusieurs Spokes. Par exemple, le siège central joue le rôle de Hub, tandis que les succursales agissent comme des Spokes.
NHRP
Le NHRP fonctionne en mode Client/Serveur. Chaque client s’enregistre auprès du serveur NHS (Next Hop Server), qui est le Hub. Les Spokes jouent le rôle de NHC (Next Hop Client). Lorsqu’un routeur Spoke souhaite envoyer un paquet à un autre Spoke, il envoie une requête à son NHS, qui lui répond en envoyant l’adresse IP du Spoke cible. Cette information est ensuite conservée dans le cache NHC pour une utilisation future.
Dans le cas où le routeur Succursale 1 souhaite envoyer un paquet à Succursale 2. Succursale 1 enverra une requête à son NHS, qui lui répondra en envoyant l’adresse IP de Succursale 2. Succursale 1 conservera cette information dans le cache NHC. L a prochaine fois qu’il en aura besoin, il la récupérera dans son cache. Succursale 1 pourra alors envoyer le paquet à Succursale 2.
Les requêtes NHRP sont appelées des requêtes underlay, tandis que les communications utilisant le VPN sont appelées overlay.
Configuration de base du DMVPN
Partons d’une topologie composée de trois sites, chacun hébergeant un seul LAN. Pour ce laboratoire, nous utiliserons le VLAN 1 par défaut (qui ne doit pas être utilisé en production). Sur chaque LAN, le NAT overload est configuré pour permettre aux machines du LAN de rejoindre le réseau WAN, simulé par un routeur.
Commençons en configurant le routeur du siège en lui appliquant une configuration de base :
Router#enable
Router#configure terminal
Router(config)#hostname RT-SIEGE
RT-SIEGE(config)#interface gig 0/0
RT-SIEGE(config-if)#ip address 192.0.0.1 255.255.255.252
RT-SIEGE(config-if)#no shutdown
RT-SIEGE(config-if)#interface gig 0/1
RT-SIEGE(config-if)#ip address 192.168.0.254 255.255.255.0
RT-SIEGE(config-if)#no shutdown
RT-SIEGE(config-if)#interface gig 0/0
RT-SIEGE(config-if)#ip nat outside
RT-SIEGE(config-if)#interface gig 0/1
RT-SIEGE(config-if)#ip nat inside
RT-SIEGE(config-if)#ip access-list standard NAT-ACL
RT-SIEGE(config-std-nacl)#permit 192.168.0.0 0.0.0.255
RT-SIEGE(config-std-nacl)#ip nat inside source list NAT-ACL interface gig 0/0
RT-SIEGE(config)#ip route 0.0.0.0 0.0.0.0 gig 0/0
Testons maintenant que notre configuration est fonctionnelle. Depuis le PC du LAN du SIEGE, après lui avoir attribuer une adresse IP, nous enverrons un PING sur l’interface LAN de notre routeur puis sur son interface WAN.
Une fois que nous nous sommes assurés du bon fonctionnement, nous continuerons.
Configurons maintenant le routeur « succursale 1 » nommé RT-SUC1
Router#enable
Router#configure terminal
Router(config)#hostname RT-SUC1
RT-SUC1(config)#interface gig 0/0
RT-SUC1(config-if)#ip address 192.0.0.5 255.255.255.252
RT-SUC1(config-if)#no shutdown
RT-SUC1(config-if)#interface gig 0/1
RT-SUC1(config-if)#ip address 192.168.1.254 255.255.255.0
RT-SUC1(config-if)#no shutdown
RT-SUC1(config-if)#interface gig 0/0
RT-SUC1(config-if)#ip nat outside
RT-SUC1(config-if)#interface gig 0/1
RT-SUC1(config-if)#ip nat inside
RT-SUC1(config-if)#ip access-list standard NAT-ACL
RT-SUC1(config-std-nacl)#ip nat inside source list NAT-ACL interface gig 0/0
RT-SUC1(config)#ip route 0.0.0.0 0.0.0.0 gig 0/0
Nous effectuerons les même test que pour le siège.
Nous enchainerons avec le routeur RT-SC2 de la succursale 2.
Router#enable
Router#configure terminal
Router(config)#hostname RT-SUC2
RT-SUC2(config)#interface gig 0/0
RT-SUC2(config-if)#ip address 192.0.0.9 255.255.255.252
RT-SUC2(config-if)#no shutdown
RT-SUC2(config-if)#interface gig 0/1
RT-SUC2(config-if)#ip address 192.168.2.254 255.255.255.0
RT-SUC2(config-if)#no shutdown
RT-SUC2(config)#interface gig 0/0
RT-SUC2(config-if)#ip nat outside
RT-SUC2(config-if)#interface gig 0/1
RT-SUC2(config-if)#ip nat inside
RT-SUC2(config-if)#ip access-list standard NAT-ACL
RT-SUC2(config-std-nacl)#permit 192.168.2.0 0.0.0.255
RT-SUC2(config-std-nacl)#ip nat outside source list NAT-ACL interface gig 0/0
RT-SUC2(config)#ip route 0.0.0.0 0.0.0.0 gig 0/0
Testons son bon fonctionnement
Pour la configuration du routeur qui simulera Internet, il n’y aura qu’une configuration d’interface.
Router#enable
Router#configure terminal
Router(config)#hostname INTERNET
INTERNET(config)#interface gig 0/0
INTERNET(config-if)#ip address 192.0.0.2 255.255.255.252
INTERNET(config-if)#no shutdown
INTERNET(config-if)#interface gig 0/1
INTERNET(config-if)#ip address 192.0.0.6 255.255.255.252
INTERNET(config-if)#no shutdown
INTERNET(config-if)#interface gig 0/2
INTERNET(config-if)#no shutdown
INTERNET(config-if)#ip address 192.0.0.10 255.255.255.252
INTERNET(config-if)#no shutdown
Vérifions que la configuration est opérationnelle.
Depuis les PC d’un des trois LAN vous devriez pouvoir envoyer des requêtes sur les différentes adresse IP public de votre lab.
Test depuis PC1
Configuration DMVPN
Configuration du Routeur RT-SIEGE [HUB]
Nous allons commencer par configurer le GRE en créant notre réseau DMVPN avec l’adresse 10.0.0.0/24 :
RT-SIEGE(config)#interface tunnel 0
RT-SIEGE(config-if)#ip address 10.0.0.1 255.255.255.0
Par défaut, le GRE est en mode point à point. Nous allons donc activer le mode mGRE pour notre VPN Multi-site :
RT-SIEGE(config-if)#tunnel mode gre multipoint
Ensuite, nous associons l’interface GigabitEthernet 0/0 à notre interface tunnel 0 :
RT-SIEGE(config-if)#tunnel source gig 0/0
Pour sécuriser la communication, nous ajoutons une authentification via une clé partagée :
RT-SIEGE(config-if)#ip nhrp authentication mdpdmvpn
Nous activons la communication multicast pour permettre aux clients de s’enregistrer dynamiquement :
RT-SIEGE(config-if)#ip nhrp map multicast dynamic
Enfin, nous attribuons un identifiant unique à notre réseau DMVPN pour permettre la coexistence de plusieurs réseaux DMVPN sur le même routeur :
RT-SIEGE(config-if)#ip nhrp network-id 1
Configuration du Routeur RT-SUC1 [Spoke]
Nous commençons par créer l’interface réseau pour RT-SUC1 :
RT-SUC1(config)#interface tunnel 0
RT-SUC1(config-if)#ip address 10.0.0.2 255.255.255.0
Ensuite, nous indiquons la clé de sécurité pour rejoindre notre réseau de tunnel :
RT-SUC1(config-if)#ip nhrp authentication mdpdmvpn
Nous devons mapper notre spoke au Hub. En bref, on précisera l’adresse IP de l’interface tunnel du Hub ainsi que son adresse IP publique :
RT-SUC1(config-if)#ip nhrp map 10.0.0.1 192.0.0.1
Activons le multicast avec le Hub :
RT-SUC1(config-if)#ip nhrp map multicast 192.0.0.1
Nous spécifions l’identifiant du réseau DMVPN que notre spoke doit rejoindre :
RT-SUC1(config-if)#ip nhrp network-id 1
Ensuite, nous enregistrons notre spoke auprès du NHS du Hub :
RT-SUC1(config-if)#ip nhrp nhs 10.0.0.1
Nous associons notre interface tunnel à l’interface WAN du routeur RT-SUC1 :
bashCopier le codeRT-SUC1(config-if)#tunnel source gig 0/0
8. Indication de la Destination du Tunnel :
Enfin, nous indiquons l’autre extrémité de notre tunnel :
RT-SUC1(config-if)#tunnel destination 192.0.0.1
Pour vérifier que le tunnel est actif, vous pouvez utiliser la commande suivante :
RT-SUC1#show dmvpn
Cette commande montre que nous formons un réseau NBMA (Non-Broadcast Multi Access) avec l’adresse 192.0.0.1.
Afin de permettre la communication entre le LAN du siège et celui de la succursale 1, il est nécessaire de configurer les routes appropriées. Bien qu’il soit possible de créer des routes statiques, nous tirerons parti du support du multicast dans notre tunnel pour mettre en place un protocole de routage dynamique. Pour cela, nous utiliserons OSPF.
Configuration du Routage Dynamique avec OSPF
Nous configurons OSPF pour indiquer les adresses réseau du LAN et du tunnel :
RT-SIEGE(config)#router ospf 1
RT-SIEGE(config-router)#network 10.0.0.0 0.0.0.255 area 0
RT-SIEGE(config-router)#network 192.168.0.0 0.0.0.255 area 0
Ensuite, nous limitons la découverte de voisinage OSPF à l’interface tunnel :
RT-SIEGE(config-router)#interface tunnel 0
RT-SIEGE(config-if)#ip ospf network broadcast
2. Configuration OSPF sur RT-SUC1 [Spoke] :
Nous suivons la même logique de configuration pour RT-SUC1 :
RT-SUC1(config)#router ospf 1
RT-SUC1(config-router)#network 10.0.0.0 0.0.0.255 area 0
RT-SUC1(config-router)#network 192.168.1.0 0.0.0.255 area 0
RT-SUC1(config-router)#interface tunnel 0
RT-SUC1(config-if)#ip ospf network broadcast
Ensuite, nous veillons à ce que les spokes ne deviennent jamais DR ou BDR en fixant la priorité à 0 :
RT-SUC1(config)#interface tunnel 0
RT-SUC1(config-if)#ip ospf priority 0
Tentons maintenant d’envoyer une requête ICMP depuis le LAN du siège vers le LAN de la succursale 1.
Lorsque la requête est envoyée, elle déclenche l’ouverture du tunnel, qui se fermera une fois la requête terminée. Ainsi, les premières requêtes peuvent échouer le temps que le tunnel s’établisse.
Configuration du routeur RT-SUC2[Spoke]
La configuration de RT-SUC2 en tant que second spoke, se configurera de la même façon que RT-SUC1 (en vert les éléments qui diffère de RT-SUC1)
RT-SUC2(config)#interface tunnel 0
RT-SUC2(config-if)#ip address 10.0.0.3 255.255.255.0
RT-SUC2(config-if)#ip nhrp authentication mdpdmvpn
RT-SUC2(config-if)#ip nhrp map 10.0.0.1 192.0.0.1
RT-SUC2(config-if)#ip nhrp map multicast 192.0.0.1
RT-SUC2(config-if)#ip nhrp network-id 1
RT-SUC2(config-if)#ip nhrp nhs 10.0.0.1
RT-SUC2(config-if)#tunnel source gig 0/0
RT-SUC2(config-if)#tunnel destination 192.0.0.1
RT-SUC2(config-if)#router ospf 1
RT-SUC2(config-router)#network 10.0.0.0 0.0.0.255 area 0
RT-SUC2(config-router)#network 192.168.2.0 0.0.0.255 area 0
RT-SUC2(config-router)#interface tunnel 0
RT-SUC2(config-if)#ip ospf network broadcast
RT-SUC2(config-if)#ip ospf priority 0
Ensuite, envoyons une requête depuis le LAN de la succursale 2 vers le LAN du siège et le LAN de la succursale 1. Les premières requêtes peuvent échouer, car elles servent à activer le tunnel, mais une fois le tunnel établi, les communications se déroulent normalement.
Sécurisation du GRE avec IPsec
Nous avons vu plus tôt que GRE n’assure pas la confidentialité des données. Pour remédier à cela, nous allons encapsuler le GRE dans un tunnel IPsec. Cette stratégie doit être configurée sur les trois routeurs [RT-SIEGE ; RT-SUC1 ; RT-SUC2 ] de notre LAB :
ROUTER(config)#crypto isakmp policy 10
ROUTER(config-isakmp)#encryption aes
ROUTER(config-isakmp)#hash sha
ROUTER(config-isakmp)#authentication pre-share
ROUTER(config-isakmp)#group 14
Nous créons une clé partagée pour tous les routeurs de notre tunnel :
bashCopier le codeROUTER(config-isakmp)#crypto isakmp key clepartage address 0.0.0.0
3. Configuration du Transform-set :
Nous configurons ensuite le transform-set :
ROUTER(config)#crypto ipsec transform-set montransformset esp-aes esp-sha-hmac
Avec IPsec, comme nous l’avons vu dans l’article VPN IPSEC il existe deux modes : Tunnel et transport. Nous utilisons IPsec en mode transport pour chiffrer les données, tandis que le tunnel est monté par GRE :
ROUTER(config)#mode transport
Nous créons un profil IPsec dans lequel nous intégrons notre transform-set :
ROUTER(config)#crypto ipsec profile monprofile
ROUTER(ipsec-profile)#set transform-set montransformset
Enfin, nous appliquons ce profil à notre interface tunnel 0 :
ROUTER(ipsec-profile)#interface Tunnel 0
ROUTER(config-if)#tunnel protection ipsec profile monprofile
En capturant le trafic entre les sites, par exemple sur la liaison WAN de mon routeur, nous observerons que toutes les communications entre mes sites sont encapsulées dans le payload des paquets IPsec (ESP), rendant impossible la lecture des données.