Résolution des problèmes de connectivité courants des instances EC2 et des erreurs

Lorsqu'une connexion EC2 échoue, la première question utile est de savoir si l'instance est inaccessible, rejette l'authentification ou n'est accessible que par le mauvais chemin. Que vous utilisiez SSH pour les instances Linux ou le protocole RDP (Remote Desktop Protocol) pour les instances Windows, les échecs de connectivité sont courants et souvent frustrants. Les erreurs SSH et RDP ont tendance à se confondre, mais Permission denied, Connection timed out, Connection refused et un écran RDP vide pointent vers différentes couches. Traitez le texte d'erreur comme un indice, puis travaillez de l'extérieur vers l'intérieur.

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

Avant de 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 ici indiquent généralement des problèmes matériels ou d'infrastructure sous-jacents qui nécessitent une intervention AWS ou l'arrêt/la recréation de l'instance.
Vérifications de l'état de l'instance : Les échecs ici sont souvent liés à des problèmes de démarrage du système d'exploitation, de corruption du système de fichiers ou de problèmes de pilotes. Si cela échoue, l'instance est probablement suffisamment défaillante pour rejeter les connexions réseau.

Action : Si l'une ou l'autre vérification échoue, envisagez d'arrêter et de redé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 obtenir des indices.

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

Assurez-vous d'essayer de vous connecter à la bonne adresse. Si votre instance doit être accessible directement depuis Internet, elle a besoin d'une adresse IPv4 publique ou d'une IP élastique et d'une route de sous-réseau public via une passerelle Internet. Si elle se trouve dans un sous-réseau privé, vous devez vous connecter via un bastion ou utiliser AWS Systems Manager Session Manager.

Astuce : Si l'instance a été arrêtée et redémarrée, son adresse IP publique peut avoir changé, sauf si vous avez 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/cle.pem).
Pour RDP (Windows) : Assurez-vous d'utiliser le bon mot de passe obtenu en déchiffrant 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 échecs les plus courants)

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

4. Règles de trafic entrant du groupe de sécurité (SG)

Les groupes de sécurité sont des pare-feu avec état attachés directement à 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 des raisons de 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 de trafic entrant requise en 0.0.0.0/0 pour le port concerné (22 ou 3389). Si vous pouvez vous connecter, le problème était que votre adresse IP client spécifique était bloquée ou mal 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 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 au niveau du sous-réseau. Ils vérifient indépendamment le trafic entrant et sortant. 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 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 essentiels. Lorsque votre client se connecte (par exemple, depuis le port 54321), le serveur répond sur un port éphémère élevé. Si la NACL 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 la NACL associée.

Phase 3 : Routage et configuration VPC

Si les couches de sécurité sont confirmées comme ouvertes, le problème réside dans la façon 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 du fait que votre instance se trouve 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 l'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 à plusieurs sauts :

Connexion via un bastion (Jump Box) : Vous vous connectez en SSH à une instance EC2 publique, puis en SSH depuis le bastion vers 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 peut bloquer la connexion. C'est courant si vous avez installé ou configuré manuellement des pare-feu locaux (comme iptables sur 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 entrantes 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.

Options de connexion publique, privée et gérée

Ne supposez pas que chaque instance EC2 doit accepter SSH ou RDP depuis Internet. Les instances publiques ont besoin d'une adresse publique, d'une route vers une passerelle Internet, de contrôles de sécurité permissifs et d'un écouteur en cours d'exécution. Les instances privées nécessitent généralement une méthode d'accès différente : un bastion, un VPN, Direct Connect, un point de terminaison EC2 Instance Connect ou Systems Manager Session Manager.

Session Manager est particulièrement utile pour les équipes d'exploitation car il peut éliminer le besoin de SSH entrant. L'instance a besoin de l'agent SSM, d'un profil d'instance IAM avec les bonnes autorisations Systems Manager et d'un accès réseau aux points de terminaison SSM. Dans les sous-réseaux privés, cela signifie généralement des points de terminaison d'interface VPC ou un accès Internet sortant via un chemin NAT. Si l'un de ces éléments manque, Session Manager n'apparaîtra pas comme une option même si l'instance elle-même est saine.

Pour une conception de bastion, testez les deux étapes. Connectez-vous d'abord de votre poste de travail au bastion. Connectez-vous ensuite du bastion à l'IP privée de l'instance cible. Le groupe de sécurité de l'instance cible doit généralement autoriser SSH uniquement depuis le groupe de sécurité du bastion, pas depuis votre IP personnelle ni depuis l'ensemble du CIDR VPC, sauf si vous avez une raison.

Pour RDP, rappelez-vous que le démarrage de Windows peut prendre plus de temps que le démarrage SSH Linux, surtout après une mise à jour ou un premier lancement. Si les vérifications d'état de l'instance viennent de réussir mais que RDP échoue toujours, vérifiez le journal système et attendez quelques minutes avant de modifier les règles de pare-feu. Remplacer à plusieurs reprises les groupes de sécurité peut masquer le problème réel de démarrage ou de service.

Tests rapides depuis votre poste de travail

Utilisez de petits tests réseau avant de modifier les ressources AWS. Depuis Linux ou macOS, nc -vz <ip-publique> 22 teste si le port TCP 22 aboutit. Pour RDP, utilisez nc -vz <ip-publique> 3389 ou un outil de test de port depuis Windows. Un délai d'attente indique un problème de routage, de groupes de sécurité, de NACL ou de pare-feu en amont. Une connexion refusée indique davantage un problème au niveau du système d'exploitation ou du service de l'instance.

Si DNS est impliqué, résolvez-le explicitement :

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

Comparez ensuite le résultat avec l'IP publique actuelle dans la console EC2. Les IP élastiques restent stables, mais les IP publiques attribuées automatiquement peuvent changer après un arrêt/redémarrage. C'est une cause simple de runbooks cassés et de profils RDP enregistrés.

Si vous utilisez un VPN d'entreprise, testez depuis un autre réseau avant de modifier la VPC. Certains réseaux d'entreprise bloquent le SSH ou le RDP sortant, et certains routeurs domestiques ou FAI interfèrent avec des ports peu courants. Une connexion réussie depuis un réseau différent vous indique que l'instance est peut-être en bon état.

VPC Reachability Analyzer est utile lorsque la route n'est pas évidente. Il peut modéliser un chemin entre une source et une destination et indiquer où le routage ou le filtrage bloque le trafic. Il ne corrigera pas une mauvaise clé SSH ou un service arrêté dans le système d'exploitation invité, mais il est utile pour séparer les problèmes de conception réseau AWS des problèmes de système d'exploitation.

Les journaux de flux peuvent également aider, surtout lorsque les NACL ou les groupes de sécurité sont suspects. Un flux rejeté depuis votre IP client vers le port 22 ou 3389 vous indique que le paquet a atteint une interface réseau ou un sous-réseau surveillé et a été refusé. Aucun flux du tout peut signifier que le trafic n'a jamais atteint la VPC, que l'adresse est erronée ou que vous regardez la mauvaise ENI, le mauvais sous-réseau ou la mauvaise fenêtre de temps.

Conservez un petit runbook d'accès pour chaque environnement : plages d'IP sources approuvées, nom du bastion, exigences SSM, noms d'utilisateur par défaut selon l'AMI et procédure d'instance de récupération. Les incidents de connectivité deviennent plus lents lorsque chaque ingénieur doit redécouvrir ces détails à partir de la console.

Notez également quels sous-réseaux sont intentionnellement privés. Cette seule note évite beaucoup de débogage inutile lorsque quelqu'un essaie de se connecter directement en SSH à une instance qui n'a jamais été conçue pour avoir un chemin Internet.

Lecture du message d'erreur

Connection timed out signifie généralement que les paquets ne terminent pas le trajet. Vérifiez l'IP publique, la table de routage, la passerelle Internet, la source du groupe de sécurité, les règles NACL, le pare-feu d'entreprise et si vous essayez d'atteindre un sous-réseau privé directement.

Connection refused signifie généralement que le chemin réseau a atteint l'instance, mais que rien n'écoute sur ce port ou que le système d'exploitation l'a rejeté. Sous Linux, vérifiez si sshd est en cours d'exécution et écoute sur le port 22. Sous Windows, vérifiez si RDP est activé et si le service Bureau à distance est en cours d'exécution.

Permission denied (publickey) n'est pas un problème de VPC. Cela signifie généralement un mauvais nom d'utilisateur, une mauvaise clé privée, une clé publique manquante dans authorized_keys, des autorisations de répertoire personnel modifiées ou une incompatibilité de nom d'utilisateur AMI, comme l'utilisation de ec2-user pour une image Ubuntu au lieu de ubuntu.

Pour Windows RDP, les échecs d'authentification proviennent souvent de l'utilisation d'un ancien mot de passe administrateur déchiffré après le remplacement de l'instance, de la connexion à la mauvaise IP publique après un arrêt/redémarrage, ou d'une stratégie de domaine remplaçant les droits de connexion locaux.

Voies de récupération lorsque vous ne pouvez pas vous connecter

Si l'instance a l'agent Systems Manager installé, un profil d'instance avec des autorisations SSM et un accès réseau aux points de terminaison SSM ou à Internet, Session Manager est généralement la voie de récupération la moins perturbatrice. Vous pouvez inspecter les journaux, corriger les règles de pare-feu ou réparer authorized_keys sans ouvrir SSH au monde.

Si SSM n'est pas disponible, utilisez la console série EC2 si elle est prise en charge, ou détachez le volume racine et attachez-le à une instance de récupération dans la même zone de disponibilité. Montez-le avec précaution, corrigez la configuration réseau ou SSH, démontez-le et rattachez-le à l'instance d'origine. Prenez d'abord un instantané afin qu'une tentative de réparation n'aggrave pas la récupération.

Lorsque la connectivité échoue, suivez cette liste de contrôle priorisée : état de l'instance, adresse correcte, nom d'utilisateur/clé ou mot de passe RDP correct, groupe de sécurité, NACL, table de routage, pare-feu du système d'exploitation et état du service. Cet ordre vous évite de modifier cinq contrôles AWS alors que le problème réel est une clé obsolète ou une route manquante.