VPN Multipoint Dynamique
La connectivité dans les réseaux WAN a évolué afin de devenir plus simple et sécurisée, maintenant que l'Internet est une méthode courante pour unifier des secteurs d'activité corporatifs distants, tels que la matrice avec ses succursales.
Une méthode permettant d’assurer une connectivité sécurisée dans les environnements publics consiste à utiliser des VPN et, dans le monde de Cisco, le GRE (Generic Routing Encapsulation) est une excellente option en raison de ses caractéristiques qui permettent la transmission de communications de diffusion (broadcast) et de multidiffusion (multicast). un problème d’évolutivité, de maintenance et de création des tunnels, puisqu’il est nécessaire d’établir manuellement les VPN pour chacune des connexions Matrix-Branch existantes.
Afin de surmonter cette difficulté, DMVPN a été créé.
Definition de DMVPN
DMVPN, par son acronyme Dynamic Multipoint VPN, utilise une méthode pour découvrir dynamiquement les destinations des tunnels créés par GRE (mGRE - multipoint GRE) et appris par NHRP - Protocole de résolution du prochain bond (Next-Hop Resolution Protocol), sans négliger la sécurité comme axe transversal de la communications via IPsec. Avec tout cela, IPsec peut très bien évoluer dans les environnements en étoile hub-and-spoke, ainsi que prendre en charge la segmentation du trafic via les VPNs et les VRFs.
Dans une implémentation IPsec typique en étoile hub-and-spoke, le routeur Hub doit avoir des crypto-cartes, des crypto ACL, des tunnels GRE et des configurations homologues ISAKMP séparément pour chaque routeur Spoke, généralement un problème d'évolutivité que DMVPN a su surmonter sans difficultés.
Dans les environnements DMVPN, les informations des routeurs Spoke ne sont pas explicitement configurées dans le routeur Hub. En échange, le Hub a une interface mGRE simple configurée, ainsi qu'un ensemble de profils qui s'appliquent aux routeurs Spokes.
Bien que les Spokes puissent désigner un ou plusieurs Hubs générant des réseaux redondants et favorisant l’équilibrage de la charge du trafic, ils ne suppriment en outre pas les caractéristiques du GRE comme le fait de prendre en charge le trafic multicast du Hub aux Spokes.
Grâce à NHRP, il est possible de déterminer l'adresse de destination des Spokes via un format de question / réponse entre clients (NHC - Next-Hop clients) et serveurs (NHS - Next-Hop Servers). Les NHC sont "enregistrés" dans le NHS.
Phases de DMVPN
Il existent trois phases de DMVPN:
- Phase 1 : Connectivité uniquement de Hub à Spoke
- Phase 2 : Capacité de communication directe entre les Spokes
- Phase 3 : Amélioration des capacités de communication entre les Spokes
Configuration DMVPN
Afin de comprendre rapidement la configuration dans les différentes phases de DMVPN, nous utiliserons la suivante topologie simple :
L'adresse IPv4 des interfaces mGRE sera du réseau 192.168.1.0/24, où:
- La Matrix de la société aura le dir. IPv4 192.168.1.1/24
- La branche 1 aura le dir. IPv4 192.168.1.2/24
- La branche 2 aura le dir. IPv4 192.168.1.3/24
Il convient de noter que les interfaces physiques de la matrice et des branches (10.1.1.1, 10.10.10.1 et 10.20.20.1) connectées au fournisseur de services Internet doivent être connectées avant la configuration de DMVPN.
Phase 1: la connectivité uniquement de Hub à Spoke
NHS - Next-Hop Server (HUB)
NHC - Next-Hop Client (Spoke)
NHC - Next-Hop Client (Spoke2)
Lors du réglage du Hub avec OSPF comme protocole de routage sur le DMVPN pour accéder à la matrice et ses branches, on doit inclure les commandes suivantes :
Et dans les Spokes:
Ceci fait, les tunnels DMVPN dynamiques dans le Hub et les tunnels statiques dans les Spokes seront en marche
Il convient de noter que pour la communication de Spoke à Spoke, le trafic passera toujours par le Hub en phase 1, par exemple pour atteindre la branche 2 (172.16.3.1) à partir de la branche 1, il y aura 2 sauts et non pas un seul :
Phase 2: Connectivité de Spoke à Spoke directement
La configuration du Hub est exactement la même dans la phase 1 comme dans la phase 2. La seule différence est que l'interface mGRE du tunnel DMVPN doit être de type Broadcast, pour pouvoir utiliser OSPF comme protocole de routage sur le réseau DMVPN.
Seulement la configuration des Spokes (Spoke - Branch 1) sera affichée, étant donné que l'interface mGRE doit également être du type Broadcast lors de la configuration de OSPF en tant que protocole de routage sur le réseau DMVPN:
La configuración del Hub es exactamente igual en la Fase 1 como en la Fase 2,
NHC - Next-Hop Client (Spoke)
Lorsque vous configurez le Spoke, il dispose d'un tunnel statique vers le Hub (NHS) et d'un tunnel dynamique vers le reste de Spokes (NHC). La connectivité est désormais directe Spoke vers Spoke (un seul saut, sans passer par le Hub).
IPSec en Phase 2:
DMVPN ne peut être conçu sans sécurité, dans la transmission de données. Donc, IPSec est un élément fondamental de cette forme de connexion, étant donné qu'il est possible de donner à cette connexion la Confidentialité, l'Intégrité, l'Authentification et la Non-Répudiation (CIA).
La configuration et les fonctionnalités d'IPSec sont similaires à celles des tunnels GRE-IPsec (IKE Phase 1, IKE Phase 2 et implémentation dans une interface), mais l'adresse de leurs paires de destination est 0.0.0.0 et elle utilise des profils IPSec.
La configuration montrée pour le Hub doit être la même que celle des Spokes:
Comme vous pouvez le constater, DMVPN est une excellente option lorsque vous cherchez un moyen sûr et évolutif, dotés d’une architecture en étoile Hub-and-Spoke, pour transmettre des informations entre différents sites d'une entreprise.
J'espère que ce sujet vous a plu. Continuez à implémenter les topologies avec DMVPN. Dans un prochain blog, je vais expliquer comment configurer la phase 3 de DMVPN.
Salutations de Quito, Equateur.
Gustavo
Publié par: Gustavo Salazar / Version originale en espagnol
