VPNs IPsec multipoints dynamiques (DMVPN)

Problématique

Ceux qui se sont déja penchés sur la question des VPN IPsec (en suivant, par exemple, ce tutoriel) ont pu rapidement se rendre compte des limites de ce protocole et en particulier, de deux d’entre elles.

Premièrement, lorsque l’on rajoute un site qui doit communiquer avec un site central, il est nécessaire de modifier la configuration de ce site central. Cela présente non seulement un problème pratique de maintenance (il faut intégrer une modification conséquente dans la configuration d’un équipement en production), mais surtout d’échelle : la configuration du site central peut devenir rapidement illisible à partir de quelques dizaines de sites distants.

Par ailleurs, si les sites distants doivent communiquer entre eux, l’équation devient impossible à résoudre. Imaginons un réseau composé d’une mairie (M) et de deux annexes (A1 et A2). Pour obtenir un réseau "full meshed" (complètement maillé, ayant des liaisons IPsec entre tous les sites), il faut créér 3 tunnels IPsec (M-A1, M-A2, A1-A2).

Maintenant, nous ajoutons une troisième annexe (sans originalité, appellons la A3). Pour continuer à avoir un réseau complètement maillé, nous devons créer 3 tunnels supplémentaires (M-A3,A1-A3,A2-A3).

Nous avons doublé le nombre de tunnels pour arriver à 6 tunnels. En fait, pour relier un nombre n de sites, nous devons configurer n(n-1)/2 tunnels, et modifier les configurations de n routeurs.

DMVPN (Dynamic Multipoint VPN) permet de résoudre ces deux problèmes : non seulement la configuration du routeur "central [1]" reste statique (elle ne change pas lorsque l’on ajoute un site distant), mais encore la création de tunnels entre sites distants est complètement automatique.

Prérequis

DMVPN s’appuyant sur des technologies et des protocoles très typés Cisco, cette solution requiert un équipement dudit contructeur, accompagné d’un IOS assez récent (12.3(11)T3).

Des configurations plus ou moins équivalentes sont cependant possibles avec d’autres solutions (Opportunistic Encryption du défunt FreeS/WAN [2], ou OpenVPN accompagné de quelques scripts), mais ne seront pas détaillées ici.

Composants et terminologie

DMVPN et en fait une combinaison des technologies suivantes :

– IPsec

Le protocole IPsec permet de chiffrer le traffic entre les différents sites.
Des clefs "wilcard psk (pre-shared keys)" (clefs pré-partagées génériques) seront utilisées. Ce n’est pas l’idéal en terme de sécurité, mais c’est ce qui permet la mise en oeuvre la plus simple et la plus rapide.

– mGRE (mutipoint GRE)

GRE permet d’encapsuler des paquets multicast, requis notamment pour les protocoles de routage ; le ’m’ de mGRE permet lui de créer des tunnels multipoints entre les sites (Ax-Ay et Ax-M), c’est à dire de créer plusieurs tunnels par une seule pseudo-interface ’Tunnel’.

– NHRP (Next Hop Resolution Protocol)

Ce protocole permet aux sites distants de faire connaitre l’adresse IP de l’interface "physique [3]" servant à monter le tunnel GRE avec le serveur. Le serveur conservera cette information pour tous les sites distants, afin de leur permettre d’obtenir l’adresse de leur voisin pour monter des tunnels directs.

– OSPF (Open Shortest Path First)

OSPF (protocole de routage) permet aux sites distants d’annoncer leur réseau local au site central, et au site central de propager la totalité des routes apprises aux sites distants.

– Hub and Spoke

Les sites sont appellés ’hub’ ou ’spoke’, en terminologie Cisco, selon qu’ils jouent respectivement le rôle de site central ou de site distant. Le site central (hub) fait office de serveur NHRP et de routeur principal (Designated Router) OSPF.

– Matériel utilisé

Cette configuration à été testée sur Cisco 831.
L’IOS minimum nécessaire est le 12.3(11)T3 (feature set IP/FW/PLUS 3DES). Attention, cet IOS requiert 48 Mo de RAM, et 12 Mo de flash.

Mise en oeuvre

– Contexte

L’objectif est de raccorder 1 site central (M) à deux sites distants (A1, A2) en utilisant DMVPN. Les configurations ci-dessous décrivent le cas d’un une mairie (M) et de deux annexes (A1, A2) reliées au réseau département ARI.

Les sites A1 et A2 n’ont pas d’adresses "officielles" ERASME. Cela n’est absolument pas nécessaire, puisque ces sites vont fonctionner "par-dessus" le réseau officiel existant.

Par ailleurs, nous allons prendre le cas le plus "défavorable", dans lequel le site central ne veut pas utiliser non plus d’adresses officielles ERASME (voir à ce sujet l’article sur les configurations IPsec sur le réseau départemental) et conserver son adressage actuel. Pour ce dernier, il sera tout de même nécessaire d’utiliser une interface Loopback pour annoncer un subnet officiel, permettant ainsi aux spokes (A1 et A2) de monter leur Tunnel GRE avec le hub (M).

Les sites distants peuvent avoir une IP statique ou dynamique sur l’interface WAN. Cela n’a pas d’importance non plus, car NHRP va gérer la résolution de ces adresses.

Le traffic intersite sera chiffré IPsec, et le traffic à destination d’Internet ne passe pas par les tunnels et sort directement au niveau de chaque site en étant NATté (translaté).

Il faut noter que la configuration présentée ici fonctionne aussi bien sur le réseau Départemental ARI que sur des sites raccordés en ADSL sur Internet (la seule différence est que le Hub devra avoir une IP WAN statique, et utiliser son interface ADSL [4] comme source du tunnel). Un déploiement mixte n’est cependant pas envisageable : c’est 100% ARI, ou 100% ADSL, mais il n’est pas possible à de jour de créér un réseau DMVPN qui relies des sites du réseau ARI et des sites raccordés en ADSL.

– Configuration du site central (hub)

Les éléments clefs de la configuration du site central sont donnés ci-dessous. Seuls ceux relatifs à la mise en place de DMVPN sont commentés. La configuration complète est donnée en fin d’article.

crypto isakmp key PRE_SHARED_KEY address 0.0.0.0 0.0.0.0

Cette commande définit la PSK ("pre-shared key", clef pré-partagée. En général une PSK est associée à un partenaire IPsec ("peer") particulier. Mais dans notre cas, nous devons utiliser une "wildcard PSK", afin d’utiliser cette clef pour tous les peers qui contacteraient le hub afin d’établir un tunnel IPsec. Cette configuration n’est pas idéale en termes de sécurité (en production, il est préférable d’utiliser des certificats), mais permet de déployer facilement une configuration sans avoir à mettre en place une PKI. Attention : il faut changer ’PRE_SHARED_KEY’ par une valeur convenable.

crypto ipsec transform-set default-ts esp-3des esp-sha-hmac 
 mode transport

Pour cette configuration il est préférable d’utiliser IPsec en mode transport. En effet, le mode tunnel encapsule le datagramme IP complet dans un paquet ESP avant de l’envoyer au destinataire. C’est le mode utilisé lorsque deux passerelles de sécurité encapsulent (mode tunnel) du traffic d’un réseau pour un autre. Dans notre configuration, ce n’est pas nécessaire, puisque ce travail est déja effectué par IP+GRE. L’utilisation du mode transport permet donc d’économiser les 20 octets d’un en-tête IP qui serait sinon placé entre ESP et GRE. Le schéma ci-dessous décrit les différentes encapsulations intervenant dans les échanges entre les sites, et le MTU en résultant pour l’interface Tunnel (voir plus bas).

crypto ipsec profile vpn_tunnel_profile
 set transform-set default-ts 

Crée un profil IPsec utilisé plus loin pour encapsuler la totalité du traffic transitant sur le tunnel.

interface Tunnel0
 bandwidth 1000
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1436
 ip nhrp authentication NHRP_KEY
 ip nhrp map multicast dynamic
 ip nhrp network-id 99
 ip nhrp holdtime 600
 ip ospf network broadcast
 ip ospf priority 2
 delay 1000
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel key 100000
 tunnel protection ipsec profile vpn_tunnel_profile 

L’interface Tunnel sert à encapsuler le traffic hub-spoke dans un tunnel IP/GRE. Compte tenu des en-têtes décrits plus haut, il faut ajuster le MTU à 1436 pour cette interface. Les commandes nhrp permettent de configurer le protocole sur cette interface, et en particulier la clef d’authentification (ip nhrp authentication), l’insertion automatique des ’spokes’ dans la liste de destinataires multicast (ip nhrp map multicast dynamic) , et la ’communauté’ NHRP (ip nhrp network-id 99).
tunnel source Loopback0 permet d’indiquer que l’interface source du tunnel est la Loopback0. Quand un paquet sera envoyé à un spoke, l’adresse IP de ce paquet (en-tête le plus à gauche du schéma) aura l’adresse IP de la Loopback0 en source.
Avec tunnel protection ipsec profile vpn_tunnel_profile, le traffic transitant par le tunnel sera chiffré selon les spécifications du profil défini plus haut.

interface Loopback0
 ip address 172.22.0.1 255.255.255.255

Cette interface (virtuelle) est la seule qui doit nécessairement être compatible avec les adresses "officielles" ERASME. Affecter une adresses en /32 suffit, tant que cette adresse est annoncée en RIPv2 sur le réseau ARI. Pour les configurations hors réseau ARI type ADSL, il n’y aura pas de Loopback et pas de RIP, mais une IP fixe (par exemple sur l’interface Dialer0). Il faudra dans ce cas ajuster tunnel source en conséquence.

interface Ethernet0
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
 ...
interface Ethernet1
 ip address dhcp
 ip nat outside

Lire la suite : VPNs IPsec multipoints dynamiques (2)