Autant le dire tout de suite, ce concept ne fonctionne que sur les équipements CISCO ... pour changer.
Le but est de simplifier la configuration des routeurs dans le cas d'un déploiement important de tunnels VPN.
Le concept met en jeux plusieurs éléments qui seront traités en plusieurs points, les tunnels mGRE, NHRP, forcément IPSEC et enfin DMVPN avec tous ces éléments mis bout à bout.
La Théorie du complot
On trouve deux architectures possibles avec les DMVPN :
- Hub et Spoke. Cette configuration requiert la création d un tunnel GRE point à point vers le Hub sur chaque Spoke et la création d'un tunnel multipoint GRE sur le Hub. Tout le trafic va transiter via le Hub.
- Spoke et Spoke. Tous les routeurs sont configurés avec des tunnels mGRE.
Comme
énoncé précédemment, DMVPN met en jeux plusieurs acteurs :
mGRE : va permettre à une interface d'être une source commune à plusieurs tunnels. On peut comparer ça à une interface série ... euh ... vite fait. On configure ce mode de façon simple grâce à la commande tunnel mode gre multipoint.
NHRP : fonctionne sur un principe client/serveur. Le Hub joue le rôle de serveur qui va stocker une base de données renseignant les adresses de tunnel et les adresses physiques des Spokes. Comment ?Au moment de la phase de boot, chaque Spoke va s’enregistrer auprès du Hub.
Voici mon architecture GNS3 :
En rouge les adresses IP des interfaces tunnels.
Configuration du tunnel mGRE
Un tunnel mGRE est très simple à configurer mais quelques points sont à pendre en considération :
Tout d'abord le HUB (R8 dans la topologie):
interface tunnel 100
ip address 10.0.0.1 255.255.255.0
tunnel mode gre multipoint
tunnel source fastethernet 1/1
On voit ici que l'on ne spécifie pas de tunnel destination, forcément il peut y en avoir plusieurs !
Les Spoke (je prends R6)
interface tunnel 100
ip address 10.0.0.2 255.255.255.0
tunnel mode gre il est en mode gre par défaut
tunnel source fastethernet 1/1
tunnel destination 192.1368.10.2 @ physique de R8
Attention à bien prendre en compte que le masque utilisé pour l'@ IP du tunnel doit permettre d' "englober" toutes les @ IP des tunnels dans le même réseau.
Configuration de NHRP
Pas difficile non plus, attention simplement à ne pas se mélanger dans les différentes @ IP. Toutes les commandes sont appliquées au tunnel.
Le Hub :
ip nhrp network-id 100 l'ID doit être identique sur tous les tunnels
ip nhrp authentication xavon doit le cas d'une configuration à travers des réseaux dont la sécurité est incertaine, configurer une authentification, ici un mot de passe xavon
ip nhrp map mulitcast dynamic NHRP va pouvoir automatiquement ajouter les mappings des Spokes dans sa base de données
Les Spokes :
ip nhrp network-id 100
ip nhrp authentication xavon
ip nhrp map mulicast 192.168.10.2 on utilise l'adresse physique de R1
ip nhrp nhs 10.0.0.1 ici c'est l'adresse IP du tunnel, on peut en configurer plusieurs si plus de un Hub
ip nhrp map 10.0.0.1 192.168.10.2 on mappe l'adresse IP du tunnel avec l'adresse physique de l'interface.
Au
final nous avons la configuration suivante sur le Hub :
interface
Tunnel100
ip
address 10.0.0.1 255.255.255.0
no
ip redirects
ip
nhrp authentication xavon
ip
nhrp map multicast dynamic
ip
nhrp network-id 100
tunnel
source FastEthernet1/1
tunnel
mode gre multipoint
Sur
les Spokes :
R6 :
interface
Tunnel100
ip
address 10.0.0.2 255.255.255.0
ip
nhrp authentication xavon
ip
nhrp map 10.0.0.1 192.168.10.2
ip
nhrp map multicast 192.168.10.2
ip
nhrp network-id 100
ip
nhrp nhs 10.0.0.1
tunnel
source FastEthernet1/1
tunnel
destination 192.168.10.2
R7 :
interface
Tunnel100
ip
address 10.0.0.3 255.255.255.0
ip
nhrp authentication xavon
ip
nhrp map 10.0.0.1 192.168.10.2
ip
nhrp map multicast 192.168.10.2
ip
nhrp network-id 100
ip
nhrp nhs 10.0.0.1
tunnel
source FastEthernet1/1
tunnel
destination 192.168.10.2
Cela marche-t-il vraiment ?
J’imagine
que certains restent sceptiques sur cette configuration …. Et
pourtant :
Voici
ce que renvoie le Hub :
R8#sh
ip nhrp
10.0.0.2/32
via 10.0.0.2
Tunnel100
created 00:03:04, expire 01:56:55
Type:
dynamic, Flags: unique registered
NBMA
address: 192.168.20.2
10.0.0.3/32
via 10.0.0.3
Tunnel100
created 00:03:04, expire 01:56:55
Type:
dynamic, Flags: unique registered
NBMA
address: 192.168.30.2
Et
oui, les deux Spokes se sont enregistrés dans la base de données du
serveur NHRP !!!!
Et
comme annonce dans l’introduction sur les architectures possibles
DMVPN, tout le trafic entre R6 et R7 va transiter via le Hub :
Le
plus fort se trouve sur le routeur Hub, après avoir lancé un debug
nhrp :
On
peut voir la résolution d’adresses IP en direct !!!
On
peut facilement voir la limitation de cette architecture, le Hub va
avoir tout le trafic à faire transiter entre les Spokes. De plus
avec IPSEC qui va se rajouter à cela, le Hub va devoir déchiffrer
et chiffrer les paquets ce qui peut vite le faire monter dans les
tours.
Et
si on parlait un peu du deuxième type d’architecture ?
Rappel :
uniquement des tunnels mGRE configurés entre les routeurs. Attention
dans ce cas la notion de Hub/Spoke n’existe plus, c’est un
concept Spoke/Spoke.
Les
interfaces tunnels sont configurées comme suit sur les R6 et R7, la
configuration de R8 ne change pas :
ip
address 10.0.0.2 255.255.255.0
no
ip redirects
ip
nhrp authentication xavon
ip
nhrp map 10.0.0.1 192.168.10.2
ip
nhrp map multicast 192.168.10.2
ip
nhrp network-id 100
ip
nhrp nhs 10.0.0.1
tunnel
source FastEthernet1/1
tunnel
mode gre multipoint
On
remarque que comme pour R8 on fait l’impasse de la commande tunnel
destination.
La
configuration de NHRP reste elle identique en tout point !! Même
si il n y a plus de Hub au niveau mGRE, il nous faut un serveur NHRP
qui enregistre les mappings !!
Voyons
ce que cela donne au niveau de R6 :
10.0.0.1/32
via 10.0.0.1
Tunnel100
created 00:08:37, never expire
Type:
static, Flags: used
NBMA
address: 192.168.10.2
10.0.0.2/32
via 10.0.0.2
Tunnel100
created 00:08:29, expire 01:51:30
Type:
dynamic, Flags: router unique local
NBMA
address: 192.168.20.2
(no-socket)
10.0.0.3/32
via 10.0.0.3
Tunnel100
created 00:08:30, expire 01:51:30
Type:
dynamic, Flags: router
NBMA
address: 192.168.30.2
Fantastique !!!
J’apprends l’adresse physique de R7 via le serveur NHRP.
Si
je relance mon traceroute comme précédemment :
R6#traceroute
10.0.0.3
Type
escape sequence to abort.
Tracing
the route to 10.0.0.3
1
10.0.0.3 96 msec * 92 msec
On
ne passe plus par R8 !!!!!!
L’intérêt
est énorme dans les grosses configurations, avec plein de routeurs
donc en théorie plein de tunnels. Les routeurs vont créer ces liens
de manière quasi automatique grâce à NHRP ! Au niveau du
troubleshoot,je ne peux pas dire si cela rend les choses plus
évidentes mais la configuration se retrouve simplifiée a
l’extrême !
Prochain
topic : on crypte les tunnels !
Bon
clic a tous,
Aucun commentaire:
Enregistrer un commentaire