Diagnostic des problèmes de connectivité des instances EC2 : Groupes de sécurité et Listes de contrôle d'accès réseau

Se connecter à une instance Amazon Elastic Compute Cloud (EC2) est une opération fondamentale, pourtant les échecs de connectivité figurent parmi les scénarios de dépannage les plus courants pour les utilisateurs AWS. Lorsqu'une instance semble fonctionner correctement mais reste inaccessible — que ce soit via SSH, RDP ou le trafic applicatif — le problème réside presque toujours dans les couches de sécurité réseau environnantes. Ce guide complet décrit l'approche systématique pour diagnostiquer et résoudre les problèmes de connectivité en se concentrant sur les trois points de contrôle réseau critiques : les Groupes de sécurité (SG), les Listes de contrôle d'accès réseau (NACL) et les Tables de routage VPC.

Comprendre la hiérarchie et la fonction de ces contrôles est essentiel. Les Groupes de sécurité agissent comme des pare-feu avec état au niveau de l'instance, tandis que les NACL agissent comme des pare-feu sans état au niveau du sous-réseau. Des configurations erronées dans l'un ou l'autre de ces composants, ou des chemins de routage incorrects, bloqueront immédiatement le trafic attendu, entraînant des délais d'attente de connexion frustrants.

Les trois piliers du contrôle de la connectivité EC2

Avant de plonger dans les configurations spécifiques, il est crucial de comprendre le rôle que chaque composant joue dans le chemin du trafic vers votre instance EC2 :

1. Tables de routage : Déterminent la direction du trafic réseau en fonction de son adresse IP de destination. Si le trafic destiné à Internet ou à l'IP de votre client ne peut pas atteindre la passerelle de sous-réseau correcte, la connectivité échouera.
2. Listes de contrôle d'accès réseau (NACL) : Appliquent des règles à un sous-réseau entier. Elles sont sans état, ce qui signifie que le trafic entrant et sortant doit être explicitement autorisé. Elles traitent les règles dans l'ordre, de la règle numérotée la plus basse à la plus élevée, s'arrêtant à la première correspondance.
3. Groupes de sécurité (SG) : Appliquent des règles directement à l'interface réseau élastique (ENI) de l'instance EC2. Ils sont avec état, ce qui signifie que si vous autorisez le trafic entrant, le trafic sortant de retour est automatiquement autorisé.

Étape 1 : Vérification des tables de routage VPC

Le premier contrôle de diagnostic doit toujours confirmer qu'un chemin existe pour que le trafic puisse atteindre le sous-réseau où réside l'instance EC2.

Vérification du routage entrant

Pour une instance accessible depuis l'Internet public (par exemple, via SSH/RDP) :

• Objectif : Assurez-vous que le sous-réseau contenant l'instance dispose d'une route vers la Passerelle Internet (IGW) pour le trafic provenant de 0.0.0.0/0 (ou de votre plage d'adresses IP client spécifique).
• Action : Accédez à la console VPC, sélectionnez Tables de routage, et examinez la table de routage associée au sous-réseau de votre instance. Recherchez une entrée comme :
  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

Vérification du routage sortant (pour les problèmes avec état)

Bien que les SG soient avec état, la vérification du chemin sortant est cruciale, en particulier pour le trafic de retour ou les instances initiant des connexions vers des services externes.

• Action : Si votre instance se trouve dans un sous-réseau privé, assurez-vous qu'elle dispose d'une route vers une Passerelle NAT ou une Instance NAT pour atteindre Internet. Si elle se trouve dans un sous-réseau public, elle devrait acheminer 0.0.0.0/0 vers l'IGW.

Conseil : Si vous ne pouvez pas effectuer un ping sur une instance depuis un sous-réseau différent au sein du même VPC, le problème est presque certainement une table de routage mal configurée dirigeant le trafic vers la mauvaise passerelle locale ou connexion de Peering VPC.

Étape 2 : Inspection des Listes de contrôle d'accès réseau (NACL) (niveau sous-réseau)

Les NACL sont souvent négligées car elles fonctionnent au niveau du sous-réseau et sont sans état. Une erreur courante est d'autoriser le trafic entrant mais d'oublier d'autoriser explicitement le trafic sortant de retour.

Vérification des règles entrantes

Pour les tentatives de connexion entrantes (par exemple, SSH sur le port 22) :

1. Identifiez la NACL associée au sous-réseau de l'instance.
2. Examinez les Règles entrantes.
3. Assurez-vous qu'une règle existe qui autorise le port et le protocole spécifiques que vous utilisez (par exemple, Règle 100 : Type : SSH (22), Protocole : TCP, Source : 0.0.0.0/0).

Vérification des règles sortantes (le piège sans état)

C'est là que la plupart des problèmes de connexion NACL surviennent.

1. Examinez les Règles sortantes.
2. Si vous avez autorisé le SSH entrant (Port 22), l'instance doit renvoyer le trafic à votre client sur une plage de ports élevés (ports éphémères), généralement 1024-65535.
3. Action : Assurez-vous qu'une règle de trafic sortant autorise explicitement le trafic vers la plage de ports de destination pertinente (souvent 1024-65535 si le client initie la connexion).

Exemple de jeu de règles NACL pour l'accès SSH entrant :

Avertissement : Les NACL évaluent les règles numériquement. Si la Règle 90 est REFUSER TOUT, votre Règle 100 AUTORISER SSH suivante ne sera jamais appliquée. Assurez-vous que vos règles AUTORISER explicites ont des numéros inférieurs à toute règle REFUSER large, ou fiez-vous à la règle implicite finale REFUSER TOUT.

Étape 3 : Audit des groupes de sécurité (niveau instance)

Les groupes de sécurité sont la dernière ligne de défense, appliquée directement à l'instance. Ils sont plus faciles à gérer car ils sont avec état.

Vérification des règles entrantes

Vérifiez que le SG attaché à l'instance EC2 autorise le trafic sur les ports requis depuis la source attendue :

• Pour SSH (Linux) : Règle entrante autorisant le port TCP 22 depuis votre IP publique ou 0.0.0.0/0 (si nécessaire).
• Pour RDP (Windows) : Règle entrante autorisant le port TCP 3389 depuis votre IP publique ou 0.0.0.0/0.
• Pour le trafic web : Règle entrante autorisant le port TCP 80 et/ou 443 depuis 0.0.0.0/0.

Vérification des règles sortantes (généralement par défaut)

Étant donné que les SG sont avec état, les règles de trafic sortant sont généralement configurées pour AUTORISER TOUT le trafic (0.0.0.0/0 sur tous les ports). Si vous avez personnalisé les règles sortantes, assurez-vous qu'elles autorisent les réponses vers la plage de ports éphémères du client.

Bonne pratique : À moins d'une exigence de sécurité stricte, laissez les règles de trafic sortant du Groupe de sécurité définies par défaut : Autoriser tout le trafic vers toutes les destinations. Cela simplifie considérablement le dépannage, car vous pouvez isoler les problèmes liés aux NACL ou aux Tables de routage.

Résumé : La liste de contrôle du flux de connectivité

Lorsqu'une connexion EC2 échoue, suivez cette séquence de diagnostic :

1. Vérification de la table de routage : Le chemin du trafic (entrant et sortant) peut-il atteindre la passerelle de sous-réseau correcte (IGW/VPC Peering/NAT) ?
2. Vérification de la NACL (sans état) : Le trafic est-il explicitement AUTORISÉ sur le port entrant spécifique ET le trafic de retour (souvent des ports éphémères élevés) est-il explicitement AUTORISÉ en sortie ?
3. Vérification du groupe de sécurité (avec état) : Le trafic est-il explicitement AUTORISÉ sur le port entrant spécifique ? (Le trafic sortant doit généralement être ouvert).

En passant systématiquement de la couche réseau large (Routage) au niveau du sous-réseau (NACL) et enfin au niveau de l'instance (SG), vous pouvez rapidement isoler si le mécanisme de blocage est un filtrage sans état, un filtrage avec état ou une défaillance de routage.