Partie 1 Partie 2 Partie 3 Partie 4
Dans les réseaux Traditionnels (DMVPN, MPLS) à grande échelle, la gestion des mises à jours de routage et l’échange des clés pour les tunnels VPN impactent les performances des routeurs. Aussi la segmentation par VRF dans les réseaux MPLS devient complexe.
Dans un réseau DMVPN combiné avec de l’IPsec, l’administrateur doit mettre en place l’authentication des routeurs participants dans le DMVPN, elle peut se faire soit avec PSK (Pre-shared Key) ou bien des certificats (Rappelez vous de la commande « auth » dans la policy isakmp ainsi que la command « crypto isakmp key address »).
la methode d’authentification la plus utilisée est le PSK, car elle est simple à configurer, c’est juste un mot de passe secret entre les deux routeurs VPN mais ce n’est pas la plus sécurisée.
Souvent dans une architecture avec plusieurs Spokes, le même PSK (le même mot de passe) est utilisé dans tous les routeurs, pire encore, la clé n’est jamais modifiée.
La méthode la plus sécurisée est d’utiliser les certificats au détriment du Pre-Shared Key. Ce qui implique que l’entreprise doit posséder sa propre infrastructure PKI. Cette méthode est plus sécurisée certes mais elle pose une complexité dans la mise en oeuvre de cette PKI et la gestion des certificats et comment les distribuer à tous les routeurs?
L’IPsec aussi est composé de deux associations de sécurité SAs, appelées Phase 1 (Isakmp) et Phase 2 (IPsec). Le rôle de la Phase 1 est de protéger la négociation de la phase 2, tandis que la phase 2 a comme rôle la protection des données.
Mais qu’est ce qui est négocié dans la Phase 2, c’est tout simplement le protocole ESP (ou éventuellement AH), c’est à dire l’algorithme de cryptage des données et l’algorithme d’integrité.
En vérité tous les routeurs participants dans le DMVPN en Spoke-to-Spoke doivent négocier deux tunnels:
1-Tunnel ISAKMP (Phase 1), par exemple 3DES, PSK et sha.
2-Tunnel IPsec (Phase 2), par exemple AES, HMAC-SHA.
Pour chaque tunnel, il y a la négociation des paramètres des deux phases, la génération de la clé de cryptage pour chaque tunnel et la vérification de l’identité (PSK ou par certificat) de chaque spoke. Dans un design complexe, les ressources des routeurs sont dégradées et la gestion de toutes ses implementations devient complexe.
Avec Cisco SD-WAN, tous les routeurs vEdges sont déja authentifiés pour joindre le Overlay du SD-WAN. Pratiquement parlant, lors du déploiement initial, pour que les routeurs Edges puissent joindre le Overlay et s’enregistrent dans vManage, il faut qu’ils s’authentifient avec des certificats avec le vBond (l’Orchestrateur), le vSmart (le Controleur) et vManage (la console de management). Le vSmart le contrôleur possède une WhiteList contenant les numéros de séries de ses vEdges (les Hubs et les Spokes). Par conséquent chaque vEdge souhaitant joindre le Overlay, il doit présenter un certificat valide et un numéro de série présent dans la WhiteList.
Si l’équipement est volé pour une raison ou une autre, il suffit juste d’invalider le certificat ou tout simplement le supprimer de la WhiteList. C’est plus sécurisé que le PSK dans le DMVPN traditionnel et une gestion simplifiée des certificats.
Le deuxieme point important est que les routeurs vEdges (Data Plane) une fois authentifiés, établiront automatiquement des tunnels DTLS avec le vSmart le controleur.
Dans la solution Cisco SD-WAN, nous avons des routeurs dont l’identité est vérifiée et des tunnels DTLS établis avec le vSmart.
Afin d’optimiser les négociations IPsec, la phase 1 qu’on connait traditionnellement et qu’on a décrit auparavant d’une manière succinte n’a pas lieu d’être entre les routeurs Edges pour générer les clés de cryptage (ses clés qui seront utilisées dans la phase 2 pour protéger les données). Mais plutôt entre les routeurs Edges et le contrôleur vSmart. Et plus judicieusement, les routeurs Edges et vSmart vont utiliser les tunnels DTLS déjà en place pour négocier les clés de cryptage. SD-WAN n’a plus besoin de la fameuse Phase 1 ISAKMP. Ses clés seront négociées à travers les tunnels DTLS à l’aide du protocol OMP.
Un attribut clé des TLOC est leur couleur. Les couleurs sont utilisées pour marquer ou classer un transport spécifique. L’administrateur réseau attribuera aux transports leurs couleurs respectives lors de l’approvisionnement des routeurs. Par exemple, tous les liens MPLS sont tagués avec une couleur et les liens Internet sont tagués avec la même ou avec une autre couleur.
Des stratégies peuvent ensuite être définies pour contrôler la manière dont le trafic de données circule dans la couche overlay.
Lors de l’établissement du Data Plane IPsec, les routeurs tenteront par défaut d’établir une connectivité en Full Mesh entre tous les routeurs de la fabric.
Si deux couleurs ont une connectivité IP, elles établiront le tunnel IPsec pour le Data Plane quelle que soit la couleur.
- BR1-Edge et BR2-Edge ont deux transports: mpls et internet.
- Ces périphériques établissent leurs connexions Control Plan avec le vSmart.
- BR1-Edge et BR2-Edge annoncent chacun deux TLOC: un pour la couleur INET et un autre pour la couleur MPLS.
- Ces deux routeurs apprendront ces routes TLOC
- BR1-Edge et BR2-Edge commencent à établir Tunnel IPsec pour le Data Plane.
- Étant donné que ces deux couleurs ont une connectivité entre elles, les routeurs établiront des tunnels IPsec pour toutes les couleurs.
Supposons, le désign nous oblige à ne pas créer de connectivité de données entre les couleurs. Dans ce cas, il existe deux options. Vous pouvez annoncer l’attribut restrict avec le TLOC, ou vous pouvez configurer des groupes de tunnels. Ces attributs indiquent aux autres périphériques de la Fabric de ne pas tenter de créer un Tunnel IPsec avec la couleur restreinte.
Grace au protocole BFD, Cisco SD-WAN Améliore et préserve la qualité de l’expérience utilisateur (vQoE) en assurant un routage intelligent des applications.
En fait, c’est assez simple, tous les routeurs d’accès qui participent à l’infrastructure SD-WAN initient automatiquement des sessions BFD au moment d’établissement des tunnels IPSEC entre eux. Ces sessions BFD monitorent en temps réel les performances de jitter, de délai et des pertes de paquets à l’intérieur des tunnels.
Multi Topologie par VPN (par VRF)
- Dans Viptela, VPN est similaire au VRF.
- VPN joue un rôle majeur dans la partie Data Plane de SD-WAN.
- Les VPNs sont identifiés par un numéro et non un nom comme les VRFs
Il y’a deux types de VPN par défaut:
- VPN0
- VPN512
La solution SD-WAN permet évidemment de conserver une flexibilité maximale avec des comportement distincts par site, par VPN, etc.
Par example: Hub&spoke régional pour un VPN “confidentiel, full-mesh pour VPN corporate etc…
Résumé de l’Opération de la Fabric:
