Dépannage des problèmes et erreurs courants de connectivité des instances EC2

La connexion à une instance Amazon Elastic Compute Cloud (EC2) est fondamentale pour la gestion de vos ressources cloud. Que vous utilisiez SSH pour les instances Linux ou le Protocole de Bureau à distance (RDP) pour les instances Windows, les échecs de connectivité sont courants et souvent frustrants. Ce guide propose une approche systématique et étape par étape pour diagnostiquer et résoudre les raisons les plus fréquentes pour lesquelles vous pourriez être incapable d'atteindre votre instance EC2.

Comprendre les échecs de connectivité nécessite de regarder au-delà de l'instance elle-même. Les problèmes proviennent généralement de mauvaises configurations dans les couches de sécurité (Groupes de sécurité, ACL réseau), d'une configuration réseau incorrecte (routage VPC) ou de problèmes d'authentification. En vérifiant méthodiquement ces composants dans l'ordre, vous pouvez rapidement isoler la cause première et restaurer l'accès.

Phase 1 : Vérifications initiales et état de l'instance

Avant de vous plonger dans des configurations réseau complexes, assurez-vous que l'instance fonctionne correctement et est accessible à un niveau fondamental.

1. Vérifications de l'état de l'instance

Utilisez la Console de gestion AWS ou l'AWS CLI pour vérifier l'état général de l'instance. Deux vérifications cruciales doivent réussir :

Vérifications de l'état du système : Les échecs à ce niveau indiquent généralement des problèmes matériels ou d'infrastructure sous-jacents qui nécessitent une intervention d'AWS ou l'arrêt/recréation de l'instance.
Vérifications de l'état de l'instance : Les échecs à ce niveau sont souvent liés à des problèmes de démarrage du système d'exploitation, de corruption du système de fichiers ou de pilotes. Si cette vérification échoue, l'instance est probablement trop malsaine pour accepter les connexions réseau.

Action : Si l'une ou l'autre de ces vérifications échoue, envisagez d'arrêter et de démarrer l'instance (ce qui la déplace vers un nouveau matériel si la vérification du système échoue) ou de consulter le journal système pour des indices.

2. Vérification de l'adresse IP publique et du nom DNS

Assurez-vous que vous tentez de vous connecter à la bonne adresse. Si votre instance se trouve dans un sous-réseau public, elle nécessite une adresse IPv4 publique ou une IP élastique. Si elle se trouve dans un sous-réseau privé, vous devez vous connecter via un hôte bastion ou utiliser AWS Systems Manager Session Manager.

Astuce : Si l'instance a été arrêtée et démarrée, son adresse IP publique a pu changer, à moins que vous n'ayez attribué une IP élastique.

3. Vérification de la configuration du client (SSH/RDP)

Les erreurs de connectivité sont parfois locales. Vérifiez que votre logiciel client fonctionne correctement.

Pour SSH (Linux/macOS) : Assurez-vous d'utiliser le bon fichier de clé privée (.pem ou .ppk) et que les autorisations sont correctement définies (chmod 400 /chemin/vers/clé.pem).
Pour RDP (Windows) : Assurez-vous d'utiliser le bon mot de passe obtenu en décryptant le mot de passe administrateur à l'aide du fichier de clé privée dans la console EC2.

Phase 2 : Diagnostics des couches de sécurité (les pannes les plus courantes)

Les mauvaises configurations de sécurité sont la principale cause des problèmes de connectivité. Les Groupes de sécurité et les ACL réseau agissent tous deux comme des pare-feu, et tous deux doivent autoriser le trafic nécessaire.

4. Règles d'entrée du Groupe de sécurité (SG)

Les Groupes de sécurité sont des pare-feu avec état (stateful) directement attachés à l'interface réseau élastique (ENI) de l'instance.

Exigences Linux (SSH) :

Protocole : TCP
Plage de ports : 22
Source : Votre adresse IP publique (Mon IP) ou 0.0.0.0/0 (pour toutes les IP, bien que cela soit déconseillé pour la sécurité).

Exigences Windows (RDP) :

Protocole : TCP
Plage de ports : 3389
Source : Votre adresse IP publique ou 0.0.0.0/0.

Étape de dépannage : Modifiez temporairement la source de la règle d'entrée requise en 0.0.0.0/0 pour le port pertinent (22 ou 3389). Si vous parvenez à vous connecter, le problème était que votre adresse IP client spécifique était bloquée ou n'était pas correctement identifiée.

Avertissement : Ne laissez jamais les groupes de sécurité ouverts à 0.0.0.0/0 pour les ports de gestion (22/3389) dans les environnements de production. Utilisez des adresses IP sources spécifiques ou des points de terminaison VPC lorsque cela est possible.

5. ACL réseau (NACL)

Les ACL réseau sont des pare-feu sans état (stateless) au niveau du sous-réseau. Elles vérifient le trafic entrant et sortant indépendamment. Si le trafic est autorisé à entrer, le trafic de retour doit également être autorisé à sortir.

Exigences NACL pour la connectivité :

Direction	Protocole	Plage de ports	Action de la règle
Entrant	TCP	22 (SSH) ou 3389 (RDP)	Autoriser
Sortant	TCP	Ports éphémères (1024-65535)	Autoriser

Les ports éphémères sont cruciaux. Lorsque votre client se connecte (par exemple, depuis le port 54321), le serveur répond sur un port éphémère à numéro élevé. Si l'ACL réseau bloque le trafic sortant sur ces ports élevés, le serveur ne peut pas vous renvoyer la réponse, ce qui entraîne un délai d'attente de connexion.

Étape de dépannage : Vérifiez que le port entrant (22/3389) et les ports éphémères sortants (1024-65535) ont une règle Autoriser dans l'ACL réseau associée.

Phase 3 : Configuration du routage et du VPC

Si les couches de sécurité sont confirmées comme étant ouvertes, le problème réside dans la manière dont le trafic est acheminé vers et depuis le sous-réseau de l'instance.

6. Type de sous-réseau et tables de routage

La connectivité dépend entièrement de la présence de votre instance dans un sous-réseau public ou un sous-réseau privé.

Connectivité du sous-réseau public

Pour un accès Internet direct (SSH/RDP depuis le monde extérieur) :

L'instance doit se voir attribuer une adresse IPv4 publique ou une IP élastique.
La table de routage associée doit avoir une route pour 0.0.0.0/0 pointant vers une passerelle Internet (IGW).

Connectivité du sous-réseau privé

Les instances dans les sous-réseaux privés ne peuvent pas être atteintes directement depuis Internet. La connexion nécessite un chemin multi-sauts :

Connexion via un hôte bastion (serveur de rebond) : Vous vous connectez en SSH à une instance EC2 publique, puis vous vous connectez en SSH depuis l'hôte bastion à l'instance privée (en utilisant son IP privée).
Connexion via VPN/Direct Connect : Si vous utilisez AWS Site-to-Site VPN ou Direct Connect, le routage doit être configuré pour diriger le trafic vers votre réseau sur site, qui achemine ensuite vers le sous-réseau privé.

7. Problèmes de pare-feu au niveau du système d'exploitation

Si les vérifications de sécurité AWS réussissent, le système d'exploitation exécuté sur l'instance EC2 elle-même pourrait bloquer la connexion. C'est courant si vous avez manuellement installé ou configuré des pare-feu locaux (comme iptables sous Linux ou le Pare-feu Windows Defender).

Diagnostic (Si possible via la Console ou Session Manager) :

Linux : Vérifiez iptables -L ou utilisez firewall-cmd --list-all. Assurez-vous que le port 22 est explicitement autorisé.
Windows : Vérifiez les paramètres du Pare-feu Windows Defender pour les règles de trafic entrant sur le port 3389.

Astuce de récupération : Si vous avez perdu toute connectivité, envisagez d'arrêter l'instance, de détacher le volume racine, de l'attacher à une instance de récupération fonctionnelle, de modifier les fichiers de configuration du système d'exploitation pour désactiver le pare-feu, puis de rattacher le volume à l'ID d'instance d'origine.

Résumé du flux de dépannage

En cas d'échec de connectivité, suivez cette liste de contrôle priorisée :

Santé de l'instance : Les vérifications d'état du système/de l'instance réussissent-elles ?
Authentification du client : Le fichier de clé est-il correct et les permissions sont-elles définies (SSH) ?
Groupe de sécurité : Le SG autorise-t-il le trafic entrant sur le port 22/3389 depuis votre IP ?
ACL réseau : L'ACL réseau autorise-t-elle le trafic entrant (22/3389) ET sortant (1024-65535) ?
Routage : La table de routage pointe-t-elle vers une IGW pour les sous-réseaux publics ?
Pare-feu du système d'exploitation : Le pare-feu local de l'instance EC2 autorise-t-il la connexion ?

En examinant systématiquement ces six domaines, vous pouvez résoudre en toute confiance la grande majorité des échecs de connectivité EC2.