Dans l’article précédent, on a parcouru ensemble les éléments fondamentaux d’un VPC ainsi que son positionnement dans l’architecture globale AWS.
Dans cet article on va détailler et décrire comment une machine EC2 pourra naviguer sur Internet.
D’un point de vue technique, pour qu’une machine dans un réseau classique puisse avoir accès à l’internet elle a besoin au minimum :
- Une adresse IP Publique configurée manuellement ou allouée via un serveur DHCP
- Une passerelle par défaut (Route) qui pointe vers un routeur qu’assure le routage
- Un serveur DNS.
Ou
- Une adresse IP Privée configurée manuellement ou allouée via un serveur DHCP
- Une passerelle par défaut (Route) qui pointe vers un routeur qui porte une adresse IP publique, ce dernier assure le routage ainsi que le fonctionnalité NAT
- Un serveur DNS
Alors comment gère-t-on ses aspects dans notre VPC ?
EC2 instance:
Après sa création, une instance EC2 récupère les informations nécessaires (IP,DNS…etc.) via le service DHCP géré par AWS (a.k.a DHCP option set).
Vous pouvez modifier les paramètres du DHCP Option Set créé par défaut au sein du VPC comme l’adresse du serveur DNS, NTP, NETBIOS ou créer des DHCP option set supplémentaires, en revanche, on ne peut associer qu’un seul DHCP Option Set à un VPC.
Pour plus d’information :
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html
La passerelle par défaut associée à chaque instance EC2 via le DHCP Set est la première adresse IP du Subnet auquel elle est attachée, cette adresse est attachée au routeur implicite géré par AWS et attaché automatiquement à chaque Subnet.
L’adresse de la passerelle allouée n’est pas modifiable via la console AWS ou à travers le CLI, mais vous pouvez toutefois la modifier en créant une route statique dans le système d’exploitation de l’instance si besoin.
Puis-je allouer une adresse IP spécifique à mon instance ?
Oui, on peut allouer une adresse IP spécifique à une instance EC2 mais seulement lors de la création de l’instance. Ceci dit, si vous changez l’adresse IP de l’instance après son démarrage depuis son système d’exploitation, la nouvelle adresse IP ne sera pas reconnue ni prise en compte.
Finalement, on sait que pour naviguer sur Internet, une instance EC2 doit se procurer d’une adresse IP publique à partir du Pool d’adresses IP publique administré par AWS. Pour en assigner une, il y’a deux méthodes, soit :
- activer le paramètre auto-assign public IPv4 address lors de création de l’instance
- Créer une adresse IP Élastique et l’associer à l’instance EC2 lors ou après sa création.
OK, maintenant mon instance EC2 possède une adresse IP privée et publique, une passerelle ainsi que l’adresse IP du DNS, c’est quoi la prochaine étape ?
Table de routage:
Par défaut, l’ensemble des Subnets au sein du VPC sont associés à une table de routage commune créé par défaut.
Ses Subnets communiquent entre eux via le routeur implicite qu’est un composant logique distribué et hautement disponible (il faut le voir comme un routeur virtuel associé implicitement à vos Subnets au sein du VPC). Ce dernier se base sur les informations de la table de routage pour les décisions de routage.
Chaque table routage au sein du VPC contient implicitement une route vers le réseau CIDR du VPC qui pointe vers le target « Local ». Aucune route plus spécifique à la route locale n’est supportée dans la table de routage.
Pour rappel, l’adresse IP du routeur implicite est la première adresse du Subnet
Chaque nouveau Subnet est associé implicitement à la table de routage par défaut, il est possible de créer une ou plusieurs tables de routage supplémentaires et associer ses tables de routage à des Subnets particuliers.
Pourquoi ferai-je cela ?
Supposant que vous avez une application composée des instances EC2 WEB et des instances EC2 APP qui hébergent votre application. Pour des raisons de sécurité, vous voulez que les EC2 WEB puissent avoir l’accès à Internet mais pas celles d’APP.
Pour répondre à ce besoin, on peut créer deux Subnets, Subnet WEB et Subnet APP puis associer au Subnet WEB une table de routage qui permet l’accès Internet et associer au Subnet APP une table de routage qui ne le permet pas.
Techniquement, une table de routage qui vous permet de naviguer sur internet doit contenir une route par défaut. Dans AWS cette route par défaut pointe sur une passerelle internet et les Subnets associés à cette table de routage sont considérés comme des « Subnets publics »,les Subnets associés à une passerelle VPN (sera détaillée dans article dédié) sont appelés des « Subnets VPN » et les autres Subnets sont appelés tout simplement des « Subnets Privés ».
Le routeur implicite préfère des routes selon l’ordre suivant :
- La route local configurée automatiquement au sein de la table de routage,
- Les routes les plus spécifiques,
- Les routes statiques sont préférées aux routes dynamiques pour la même destination,
- Les routes dynamiques propagée par le Direct Connect
- Les routes statiques qui pointent vers une passerelle VPN
- Les routes dynamiques propagées par une passerelle VPN
Passerelle Internet:
La passerelle internet AWS (IGW) est un composant AWS scalable, redondant et hautement disponible, son rôle primaire est de relier les Subnets de votre VPC à l’internet.
Une passerelle Internet a deux finalités : elle fournit une cible dans vos tables de routage VPC pour le trafic routable sur Internet et elle effectue la conversion d’adresse réseau (NAT) pour les instances auxquelles ont été affectées des adresses IPv4 publiques. Eh oui comme vous voyez, l’adresse IP Publique qu’on a associé à l’instance EC2 plus haut dans cet article n’est pas vraiment associée à l’instance mais c’est plutôt un NAT statique qu’est programmé au niveau de l’IGW pour faire une translation mutuelle entre l’adresse IP privée de l’instance et l’adresse IP publique associée au niveau de l’IGW.
Peut-on à cette étape naviguer sur internet ??
Non pas forcément , il faut associer une ACL réseau au Subnet et un groupe de sécurité à l’instance EC2.
ACL réseau:
Une ACL réseau est une couche de sécurité qui agit au niveau du Subnet, elle légifère la communication du Subnet avec le monde externe.
Une ACL réseau est une liste ordonnée de règles qu’AWS évalue, en commençant par la règle dont le numéro le plus bas, pour déterminer si le trafic est autorisé d’entrer ou de sortir. Chaque ACL possède une règle implicite (Implicit Deny) qui bloque tout le trafic. Par défaut le Subnet est associé à une règle qu’autorise tout le trafic dans les deux sens IN/OUT.
Les ACL fonctionnement en mode Stateless, c’est-à-dire que pour un flux donné il faut définir deux règles, une dans le sens de sortie et une dans le sens d’entrée.
Prenant l’exemple d’un serveur WEB accessible depuis l’internet via HTTPs, la règles ACL associée au Subnet du serveur WEB doit contenir à minima les deux règles suivantes :
Groupe de sécurité (Security Group) :
Un groupe de sécurité est un pare-feu virtuel « Statefull » distribué qui contrôle le trafic entrant et sortant des ressources AWS et des instances EC2. Par défaut les instances EC2 sont associées à un groupe de sécurité créer par défaut au sein du VPC, les ressources attachées à ce groupe de sécurité sont autorisées de communiquer entre eux, le groupe par défaut autorise la communication avec le mode externe et il bloque implicitement le reste. Vous pouvez modifier les règles du groupe de sécurité par défaut mais vous n’avez pas le droit de le supprimer.
Vue la nature « Statefull » du groupe de sécurité, une règle qui autorise le flux en entrée le trafic de retour de ce flux est autorisé automatiquement.
L’exemple ci-dessous autorise l’accès en HTTPs depuis internet et en SSH depuis l’adresse 192.168.1.1 à une instance EC2:
Le tableau ci-dessous résume la différence entre le groupe de sécurité et l’ACL
| Groupe de sécurité | ACL réseau |
| S’associe à l’interface de l’instance | S’associer au Subnet |
| Supporte seulement les règles Allow | Supporte les règles Allow et Deny |
| Stateful: le trafic de retour est autorisé automatiquement | Stateless, le trafic de retour doit être autorisé |
Network Address Translation (NAT) :
Les instances dans les Subnets privés n’ont pas la possibilité de communiquer avec l’IGW et accéder à l’Internet car leurs table de routage ne contient pas une route par défaut qui pointe vers l’IGW. Ces instances peuvent avoir besoin d’une connexion Internet sécurisé pour télécharger des mises à jour ou des correctifs des bugs systèmes. Ayant conscience de ce besoin, AWS propose deux alternatives qui permettent aux instances (IPv4) déployées dans un Subnet privés puissent avoir accès à l’internet. C’est à travers l’instance NAT ou la passerelle NAT. AWS privilégie l’utilisation de la passerelle NAT car il offre plus de scalabilité/disponibilité, plus de bande passante et moins d’effort par rapport à l’instance NAT. La passerelle NAT ou l’instance NAT assure la fonctionnalité PAT (Port Adresse Translation) pour permettre de faire sortir plusieurs adresse IPv4 privées via une seule adresse IP publique.
Il faut noter que cette fonctionnalité est réservée exclusivement au trafic IPv4.
L’instance NAT:
L’instance Nat est une machine Linux programmée par AWS et fait partie de la famille Amazon Machine Image) conçu pour accepter le trafic en provenance des instances dans les Subnets privés, remplacer l’adresse source par celle de l’instance NAT puis acheminer le trafic vers la passerelle NAT.
Pour accomplir cette mission, l’instance NAT doit :
- Être dans un Subnet public
- Posséder une adresse IP publique
- Autoriser le passage de trafic du transit (désactivé par défaut) en désactivant l’option Check Source/Destination
- Être la cible de la route par défaut dans les tables de routages des Subnets privés.
La passerelle NAT:
La passerelle NAT est une ressource managée par AWS conçu pour assurer le même service que l’instance NAT d’une façon simple, scalable et hautement disponible au sein de l’AZ.
Pour accomplir sa mission, la passerelle NAT doit :
- Être positionnée dans un Subnet public
- Posséder une adresse IP publique
- Être la cible de la route par défaut dans les tables de routages des Subnets privés.
Le tableau ci-dessous liste les options supportées par la passerelle NAT et l’instance NAT:
| Option | Passerelle NAT | Instance NAT |
| Disponibilité | Hautement Disponible, Créer une Passerelle NAT dans chaque Zone de disponibilité permet d’assurer une haute disponibilité indépendante par zone de disponibilité | Nécessite un script pour assurer la reprise d’activité |
| Bande Passante | Support jusqu’à 10Gbps | Dépend de la bande passante du type de l’instance |
| Maintenance | Managée et maintenue par AWS | Vous assurez la maintenance de l’instance comme la mise à jour du système d’exploitation et l’installation des patches |
| Coût | Vous payez le nombre des passerelles NAT utilisées, le temps d’usage et la quantité des données envoyés par la passerelle. | Vous payez le nombre des instances NAT utilisées, le temps d’usage ainsi que le type et la taille d’instance |
| Type et taille | Une offre uniforme, la passerelle NAT scale verticalement et horizontalement pour répondre au besoin | Vous devez choisir manuellement le type de la taille de l’instance idéale pour traiter le trafic à natter |
| Port Forwarding | Non supporté | Vous pouvez modifier la configuration pour supporte le Port Forwading |
Dans cet article, on a déroulé l’ensemble des éléments qui nous permettent d’assurer le service Internet aux instances EC2 dans les Subnets publics et les Subnets privés. Dans le prochain article on expliquera comment permettre aux instances EC2 de consommer des services publique AWS directement sans passer par l’Internet.
Si vous avez des questions, un autre avis sur le sujet ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.
