Diagnostic des problèmes de connectivité des instances EC2 : Groupes de sécurité et ACL réseau

Lorsque votre instance EC2 est en cours d'exécution mais que le trafic SSH, RDP ou d'application expire, le problème se situe généralement dans le chemin réseau autour de l'instance. Diagnostiquez la connectivité EC2 en vérifiant d'abord la table de routage, puis l'ACL du sous-réseau, puis le groupe de sécurité de l'instance.

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 erreurs de configuration 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 de chaque composant dans le chemin de trafic vers votre instance EC2 :

Tables de routage : Déterminent où le trafic réseau est dirigé en fonction de son adresse IP de destination. Si le trafic destiné à Internet ou à l'adresse IP de votre client ne peut pas atteindre la passerelle de sous-réseau correcte, la connectivité échouera.
ACL 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 haute, en s'arrêtant à la première correspondance.
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

La première vérification de diagnostic doit toujours confirmer qu'un chemin existe pour que le trafic atteigne même le sous-réseau où se trouve l'instance EC2.

Vérification du routage entrant

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

Objectif : Assurez-vous que le sous-réseau contenant une instance publique a une route par défaut vers une passerelle Internet (IGW).
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 | Cible : 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 a une route vers une passerelle NAT ou une instance NAT pour atteindre Internet. Si elle se trouve dans un sous-réseau public, elle doit router 0.0.0.0/0 vers l'IGW.

Astuce : Le trafic entre les sous-réseaux du même VPC utilise normalement la route locale implicite. Si ce trafic échoue, vérifiez les groupes de sécurité, les NACL, les pare-feu hôtes et si la destination autorise ICMP avant d'incriminer la table de routage.

Étape 2 : Inspection des ACL réseau (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 consiste à autoriser le trafic entrant mais à 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) :

Identifiez la NACL associée au sous-réseau de l'instance.
Examinez les règles entrantes.
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 se produisent.

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

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

Règles entrantes :

N° règle	Type	Protocole	Plage de ports	Source	Autoriser/Refuser
100	SSH	TCP	22	IP client/CIDR	AUTORISER
*	*	*	*	*	REFUSER (Par défaut)

Règles sortantes :

N° règle	Type	Protocole	Plage de ports	Destination	Autoriser/Refuser
100	TCP personnalisé	TCP	1024-65535	IP client/CIDR	AUTORISER
*	*	*	*	*	REFUSER (Par défaut)

Avertissement : Les NACL évaluent les règles numériquement. Si la règle 90 est REFUSER TOUT, votre règle 100 suivante AUTORISER SSH ne sera jamais atteinte. 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 sortantes 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.

Meilleure pratique : Sauf s'il existe une exigence de sécurité stricte, laissez les règles sortantes 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 de NACL ou de table de routage.

Liste de vérification de la connectivité

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

Vérification de la table de routage : Le chemin de trafic (entrant et sortant) peut-il atteindre la passerelle de sous-réseau correcte (IGW/Peering VPC/NAT) ?
Vérification 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 ?
Vérification du groupe de sécurité (avec état) : Le trafic est-il explicitement AUTORISÉ sur le port entrant spécifique ? (La sortie doit généralement être ouverte).

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.