Contactez-nous
-
cloud public

Implémentation d’une architecture Cloud Hybrid sur AWS

Cloud Hybrid sur AWS

Sommaire

Configuration de Direct Connect et Basculement Site-To-Site VPN  à travers Transit Gateway

Nombreuses sont les entreprises qui exploitent à présent les solutions du cloud computing disponibles sur le marché, afin de bénéficier des multiples avantages qu’offrent ces technologies.

Mais face à cette exploitation, on se retrouve souvent avec le besoin d’établir une connexion réseau dédiée et sécurisée entre le cloud public et l'infrastructure privée on-premise de l’entreprise.

Comment peut-on faire pour réaliser cette connexion réseau d’une manière sécurisée, en gardant l’indépendance et l'intégrité de chaque partie ?

Dans cet article nous allons répondre à cette question en traitant un cas réel.

Notez bien que la lecture de cet article demande des connaissances sur les aspects réseaux (TCP/IP, routage statique / dynamique, sécurité …) et aussi un minimum de connaissances sur les services AWS qui ont un fonctionnement lié à la partie réseau (VPC , VPN , Internet gateway , Network ACL …)

Alors, il s’agit d’établir une connexion entre le réseau AWS et le réseau on-premise qui dessert l’infrastructure privée de l'entreprise en utilisant une interconnexion dédiée Direct Connect.

Celle-ci sera la principale et une autre interconnexion, Site-To-Site VPN, sera utilisée comme solution de secours. Le tout est rendu disponible via une passerelle Transit Gateway qui sera l'élément central de cette architecture.

Commençons par tracer un schéma global qui présente l’architecture hybride cible pour ensuite détailler ses composants :

 

Transit Gateway (TGW)

Introduit lors du AWS re:Invent 2018, AWS Transit Gateway est l'élément-clé pour simplifier la gestion des connexions réseaux sur AWS et de fusionner les ressources cloud et on-premise dans une seule topologie réseau.

Transit Gateway agit comme un routeur virtuel régional pour le trafic circulant entre les VPC dans la même région, VPN et Direct Connect que nous allons attacher à ce service. Le routage au niveau de ce service fonctionne au niveau de la couche 3 du modèle OSI.

Les paquets sont envoyés vers le next-hop attachement (la liaison de la Transit Gateway qui envoie vers le service cible) en se basant sur leur adresses IP de destination.

Transit Gateway est un service régional, si besoin de communiquer entre deux régions nous pouvons relier deux Transit Gateways.

Avantages :

  • Simplifie la connectivité et le design de l’architecture réseau.
  • Service entièrement managé par AWS.
  • Simplifie la visibilité et le contrôle réseau.
  • Bande passante jusqu’à 50 Gbps pour chaque attachement VPC / TGW.

Limites :

  • TGW ne support pas l’overlapping entre VPC.
  • 20 tables de routage maximum par TGW.

Dans cette implémentation, nous allons utiliser les trois types de connexion possibles via une Transit Gateway :

  • VPC.
  • Customer Gateway (VPN).
  • Direct Connect.

Sachant qu'une fois la Transit Gateway attachée à la fois avec Direct Connect et Site to Site VPN, elle va utiliser par défaut la liaison Direct Connect pour les mêmes routes.

 

Direct Connect (DX)

AWS Direct Connect est un service qui vous permet d’établir une interconnexion entre le réseau privé (on-premise) et l'un des emplacements de AWS Direct Connect selon la région que nous allons utiliser.

Physiquement, il s’agit une connexion dédiée en câble fibre optique dont l’une des extrémités est votre routeur privé et l’autre est un routeur d’AWS Direct Connect.

Direct Connect est un service global , il existe plusieurs types d’interconnexion pour le Direct Connect hébergé et dédié. Dans notre cas, nous allons choisir une interconnexion dédiée pour mutualiser le flux des données en transit et avoir plus de sécurité.

Avantages :

  • L’homogénéité des performances réseaux.
  • Connexion haut débit de 10 Gbps.
  • Réduction des coûts réseaux.
  • La connectivité privée à votre Amazon VPC.
  • La compatibilité avec tous les services AWS.

Limites à l’usage avec TGW :

  • Le nombre maximal des routes BGP annoncées depuis le on-premise vers la TGW est de 100.
  • Dans notre cas, il s’agit d’une connexion dédiée donc le débit est 1 Gbps ou 10 Gbps. Il n’est pas possible de choisir entre ces deux valeurs.
  • Une seule Virtual Interface par Direct Connect.
  • Pas de chiffrement par défaut des données en transit.
  • Le nombre maximal des routes BGP annoncées depuis la TGW vers le on-premise est de 20.

 

AWS Site-To-Site VPN

Bien que le terme connexion VPN soit aujourd’hui commun, le service AWS Site-To-Site VPN est un service régional qui fait référence à la connexion entre un VPC et un réseau privé on-premise. Il prend en charge les connexions VPN utilisant l'Internet Protocol Security (IPsec).

Avantages :

  • Liaison VPN possible avec Transit Gateway.
  • Prise en charge de Internet Key Exchange version 2 (IKEv2): Il s’agit  d’une  technique de cryptographie asymétrique utilisée pour sécuriser une connexion en authentifiant les deux parties.
  • Pour plus d’informations sur ce protocole, voici un article intéressant le détaillant.
  • Support de multiples équipements pour la Custom Gateway.
  • Création de deux tunnels pour assurer la haute disponibilité.

Limites :

  • Bande passante de 1,25 Gbit/s par Tunnel.
  • 50 Customers Gateway par région.
  • 100 routes dynamiques qui peuvent être propagées par Custom Gateway.

Une fois que nous avons listé les services AWS que nous allons utiliser et les services que nous allons exploiter, il est temps de définir les prérequis pour la mise en oeuvre de cette solution.

  • Définir la région AWS à utiliser : dans notre cas nous choisissons eu-west-3 (Paris).
  • Activer le protocole BGP dans les routeurs du réseau privé (on-premise). À savoir que sans le BGP, les routes ne peuvent pas se propager automatiquement et nous aurons besoin de créer des routes statiques.

Plus de détails concernant le protocole BGP ici :

  • Définir les plages d'adresses réseaux de chaque zone pour éviter l’overlapping entre AWS et on-premise.
  • Structurer les listes des contrôles d'accès par VPC (ACLs).
  • Définir les caractéristiques du Direct Connect souhaitées, à savoir la bande passante et l’emplacement. Il existe plusieurs fournisseurs selon la région utilisée pour demander des interconnexions.

 

Now, let's get our hands dirty

Pour réaliser cette architecture réseau sur AWS nous allons utiliser Terraform.

L’ensemble du code Terraform est disponible dans le GitLab de WeScale.

 

VPC :

Nous allons commencer par créer un module Terraform qui va contenir l’ensemble des ressources à déployer au niveau de chaque VPC :

  • Un VPC de transit (VPC attaché à la Transit Gateway).
  • Un sous réseau que nous allons utiliser pour créer des instances EC2 qui vont communiquer avec le réseau privé (on-premise).
  • Une internet gateway pour donner accès internet à cette instance EC2.
  • Une table de routage que nous allons associer avec le VPC.
  • Les routes nécessaires pour le routage local, de transit et vers internet.
  • Les associations entre la table de routage sous-réseau et VPC.
  • Les Network Access Control List (NACLs) pour maîtriser le flux entrant / sortant dans le sous-réseau.
  • La table de routage de la Transit Gateway dédiée au VPC.
  • Un attachement type VPC entre la Transit Gateway et VPC.
  • Une association entre l’attachement et la table du routage du VPC.
  • Une propagation entre l’attachement et la table de routage de la Transit Gateway.
  • Un VPC Flow log pour avoir la traçabilité sur le flux réseau.
  • Un DNS Resolver endpoint en mode OUTBOUND  pour pouvoir appeler des DNS internes dans le réseau on-premise.

N.B : Lien vers le code.

VPN :

Maintenant que la partie réseau de l’architecture est prête, nous allons pouvoir nous pencher sur la création d’un module VPN qui sera notre solution de failover automatique : elle sera également attachée à la Transit Gateway sera en mesure de router le trafic vers le VPC de transit si la solution principale d’interconnexion Direct Connect tombe.

Ce module contient :

  • Une VPN customer gateway qui sera le routeur on-premise qui va gérer le IPsec Site-To-Site VPN (Pfsense, Cisco ASA, ou Palo Alto par exemple).
  • Un site to site VPN connexion entre la Customer Gateway et la Transit Gateway incluant deux tunnels pour assurer la HA.
  • La table de routage de la Transit Gateway dédiée à la Customer Gateway.
  • Un attachement type VPN entre la Transit Gateway et la connexion site-to-site VPN.
  • Une association entre l’attachement et la table de routage du VPN.
  • Une propagation entre l’attachement VPN et la table de routage de la Transit Gateway.

N.B : Lien vers le code.

 

Direct Connect  :

Nous sommes maintenant arrivés à la création du module Terraform pour le Direct Connect qui va être notre solution principale d’interconnexion dédiée entre le réseau d’AWS et le réseau on-premise.

Ce module se compose de :

  • Direct Connect Connection.
  • Direct Connect Gateway pour identifier la Transit Gateway qui va être utilisée avec le Direct Connect et établir l’association entre les deux (on ne peut faire qu’une seule association par Direct Connect).
  • La virtual Interface de transit  (VIF) qui permet d’accéder à la Transit Gateway via la Direct Connect Gateway.
  • La table de routage de la transit gateway dédiée au Direct Connect.
  • Un attachement type Direct Connect entre la Transit Gateway et le Direct Connect.
  • Une association entre l’attachement Direct Connect et la table du routage du Direct Connect.
  • Une propagation entre l’attachement Direct Connect et la table de routage du Direct Connect.

N.B : Lien vers le code.

Main :

Enfin, il ne nous reste qu'à déployer la Transit Gateway avec les trois modules que nous avons créés à l’avance et réaliser les associations, propagations désirées vu que nous n'avons pas choisi qu'AWS s'occupe de les créer automatiquement pour nous : pratique, non ?!

N.B : L'exemple que nous allons déployer ensemble est pour le scénario d'un seul compte AWS, mais il peut facilement être étendu sur des scénarios multi-comptes en utilisant AWS Resources Access Manager et en dupliquant le module VPC que nous avons fabriqué au préalable.

Les valeurs que nous allons utiliser au niveau du code terraform pour l’ensemble des ressources sont des valeur imaginaires, mais pour que ce déploiement fonctionne correctement pour vous, il faut faire attention aux points suivants :

  • Utiliser un autonomous system number différent pour chaque ressource (Transit Gateway, VPN Customer Gateway, Direct Connect, Transit Virtual Interface) pour définir chaque ressource comme un AS (autonom system) https://www.bgp.us/ibgp-and-ebgp/.
  • Renseigner la bonne valeur de la localisation et de la bandwidth du Direct Connect qu’on récupère depuis le fournisseur d’interconnexion pour la Direct Connect connection.
  • Valider les préfixes des CIDRs privés (les CIDRs des sous réseaux privés que nous souhaitons autorisé à communiquer avec le réseau AWS).
  • Valider les CIDRs blocs des VPC et des réseaux on-premise pour éviter les overlapping.
  • Récupérer un VLAN tag  qui a doit être créé par l’équipe réseau on promise pour le Direct Connect dans le cas d’une interconnexion dédiée.

Sans le VLAN tag le flux ne passera pas à travers le Direct Connect

Cette valeur comprise doit être comprise entre 1 et 4094 doit être unique et compatible avec le standard VLAN 802.1q

  • Récupérer  l'adresse ip de l'interface publique du routeur on-premise pour l’utiliser au niveau de AWS Custom Gateway pour faire la connexion VPN et assurer que le BGP est activé.

Une fois que tout est bon pour ces éléments, la structure finale de ce projet va ressembler à ça :

Nous sommes prêts à exécuter les commandes Terraform dans l'ordre suivant :

terraform init
terraform plan
terraform apply

Désormais nous disposons d’une architecture hybride qui relie le réseau d’AWS avec celui de l'entreprise à travers une interconnexion Direct Connect et un Failover automatique via une Liaison IPsec Site-To-Site VPN.

On peut alors imaginer le niveau de flexibilité dont nous disposons maintenant, l'élasticité pour faire face à la variation de la demande, les réductions considérables de coûts que nous pouvons réaliser (temps de réalisation, ressources ...)  mais aussi les avancements que nous pouvons accomplir sur nos projets (migration de données, métiers, big data) grâce à l’utilisation des services entièrement managés.

"With great power comes great responsibility."

Nous avons vu ensemble comment réaliser une topologie réseau hybride grâce à AWS Transit Gateway et Direct Connect, ces services ouvrent de nouvelles possibilités d’interconnexion et de connectivité permettant de construire des architectures réseaux complexes et sécurisées, mais qui présentent aussi des risques si nous ne savons pas comment les exploiter.

Ainsi, il est indispensable de se servir des outils de visualisation et de traçabilité comme Network Manager, VPC Flow logs, Network ACLs et Trafic Mirroring pour éviter toutes les escalades et les ouvertures de flux non souhaitables.