Relier deux sites distants à travers Internet pose un problème en deux temps : il faut d'abord faire circuler le trafic comme s'il s'agissait d'un seul réseau, puis protéger ce trafic une fois qu'il quitte le terrain connu pour emprunter un chemin public. Le tunnel GRE répond au premier problème : il encapsule n'importe quel trafic, y compris les mises à jour de protocoles de routage, dans un lien virtuel point à point. IPsec répond au second : il chiffre et authentifie ce qui circule dans ce lien. Combinés, GRE et IPsec forment l'une des architectures de VPN site à site les plus répandues dans les réseaux d'entreprise. Ce laboratoire les met en œuvre ensemble, avec en prime une couche de NAT et une VM Linux pour observer le résultat du point de vue de l'utilisateur.
Le laboratoire
La maquette relie deux sites, HQ et Branch, à travers un routeur ISP qui simule Internet. Côté HQ, deux interfaces loopback représentent le réseau interne (10.10.10.0/24) et un serveur de messagerie (10.10.20.238) ; côté Branch, une interface loopback représente un second réseau interne (192.168.1.0/24), tandis qu'une véritable machine virtuelle Linux, CCNP_VM, est connectée au commutateur du site (172.20.20.0/24) pour servir de poste de test. Chaque routeur de site dispose d'une interface tournée vers l'ISP avec une adresse publique simulée (209.165.200.226 pour HQ, 209.165.200.242 pour Branch), point de départ du tunnel et point d'ancrage du chiffrement. Le panneau de droite reprend l'essentiel des configurations des deux routeurs : interfaces, tunnel, cryptographie, routage et NAT.
Le tunnel GRE : un lien logique entre les deux sites
Un tunnel GRE (Generic Routing Encapsulation) crée un lien virtuel point à point entre deux routeurs, par-dessus n'importe quel réseau IP intermédiaire. Sur HQ comme sur Branch, l'interface Tunnel0 reçoit une adresse dans le réseau 172.16.100.0/30, une source (l'interface publique du routeur local) et une destination (l'interface publique du routeur distant) : dès que ces deux extrémités se voient, le tunnel monte, et le routeur dispose d'une interface toute neuve à annoncer dans son protocole de routage. EIGRP est alors activé sur les deux sites, avec le réseau du tunnel et les réseaux internes de chaque site dans sa liste d'annonces. Résultat : HQ apprend les réseaux de Branch via Tunnel0, et inversement, comme s'ils étaient connectés en direct.
Chiffrer le tunnel : ISAKMP, IPsec et crypto map
Un tunnel GRE transporte le trafic, mais ne le protège pas : tel quel, il circule en clair sur Internet. C'est là qu'intervient IPsec, posé par-dessus le GRE selon un montage classique appelé GRE over IPsec. La négociation se déroule en deux phases : crypto isakmp policy définit les paramètres de la phase 1 (chiffrement AES, authentification par clé pré-partagée cisco123, groupe Diffie-Hellman 2) qui établissent un canal sécurisé entre les deux routeurs ; crypto ipsec transform-set définit ceux de la phase 2 (ESP avec chiffrement 3DES et authentification SHA) qui protègeront ensuite les données elles-mêmes. Une crypto map rassemble ces éléments, désigne le routeur distant comme correspondant et s'appuie sur une liste de contrôle d'accès pour décider quel trafic mérite d'être chiffré. Et précisément : cette liste ne retient qu'une seule chose, le trafic GRE échangé entre les deux adresses publiques (permit gre host 209.165.200.242 host 209.165.200.226). Autrement dit, ce n'est pas le trafic utilisateur qu'IPsec voit passer, mais le tunnel GRE tout entier, déjà chargé de tout ce que ce trafic utilisateur contient.
NAT : laisser passer le VPN, traduire le reste
Le tunnel chiffré s'occupe du trafic entre les deux sites. Mais qu'en est-il du trafic qui part vers le grand Internet, par exemple depuis le poste de travail de Branch ? C'est là qu'intervient une seconde logique, le NAT, et elle doit cohabiter intelligemment avec la première. Sur chaque routeur de site, une liste de contrôle d'accès trie le trafic sortant en deux familles : celui qui va vers les réseaux internes de l'autre site (deny ip 192.168.1.0 0.0.0.255 10.10.0.0 0.0.255.255) n'est jamais traduit, il garde son adresse d'origine pour emprunter le tunnel sans encombre ; tout le reste (permit ip ... any) est traduit dynamiquement vers une adresse publique piochée dans un pool dédié, avant de poursuivre sa route vers Internet via l'ISP. HQ ajoute même une translation statique permanente (209.165.200.238 vers 10.10.20.238), pour que son serveur de messagerie reste joignable depuis l'extérieur.
Vérification : tester la maquette depuis la VM Linux
Toutes ces couches, tunnel, chiffrement, routage, traduction d'adresses, ne valent que par ce qu'elles permettent concrètement de faire. Depuis CCNP_VM, la machine Linux connectée au réseau de Branch, deux tests simples suffisent à le vérifier : un ping vers 8.8.8.8 pour confirmer l'accès à Internet via le NAT, et le chargement d'un site web réel dans un navigateur pour le constater à l'œil nu.
Le ping vers 10.10.10.1 laisse deviner quelque chose d'intéressant : la réponse revient avec un TTL à peine entamé, comme si peu d'étapes séparaient la VM du réseau de HQ. Une trace de route le confirme sans détour.
Reste un dernier point à vérifier : la table de routage de HQ a-t-elle changé depuis que le chiffrement est entré en jeu ?
C'est tout l'intérêt du montage : IPsec vient se glisser sous le tunnel GRE sans rien lui demander en retour. Le routage continue son travail, les adjacences EIGRP tiennent bon, les deux sites continuent de se voir comme des voisins directs, exactement comme avant. La seule différence, invisible à ce niveau, c'est que tout ce trafic circule désormais chiffré sur le réseau public : la sécurité s'est ajoutée à un étage entièrement différent, sans que la couche du dessus ait eu à s'en apercevoir.