Comment diagnostiquer et résoudre les problèmes courants de connectivité des instances EC2

Les problèmes de connectivité EC2 se résument généralement à un saut bloqué : l'instance, le groupe de sécurité, les règles du sous-réseau, la table de routage ou le chemin de la passerelle. Si vous ne pouvez pas vous connecter en SSH à une instance EC2, atteindre un port d'application ou connecter une instance à une autre, parcourez le chemin réseau dans l'ordre au lieu de modifier les règles au hasard.

Les vérifications ci-dessous vous aident à isoler l'endroit où le trafic s'arrête et à appliquer la correction la plus petite qui rétablit l'accès.

Causes courantes des problèmes de connectivité EC2

Les problèmes de connectivité peuvent provenir de différentes couches de la pile réseau AWS. L'identification de la cause racine implique souvent de vérifier une combinaison de ces éléments :

Groupes de sécurité : Ce sont des pare-feu virtuels avec état attachés aux interfaces réseau élastiques. Ils contrôlent le trafic entrant et sortant au niveau de l'instance.
Listes de contrôle d'accès réseau (NACL) : Les NACL opèrent au niveau du sous-réseau et fournissent une couche supplémentaire de filtrage sans état pour le trafic entrant et sortant des sous-réseaux.
Tables de routage : Elles déterminent où va le trafic du sous-réseau, par exemple localement dans le VPC, vers une passerelle Internet, vers une passerelle NAT ou vers une passerelle de transit.
État de l'instance et configuration réseau : Problèmes avec l'instance EC2 elle-même, comme son arrêt ou des paramètres d'interface réseau incorrects.
Passerelle Internet (IGW) / Passerelle NAT : Pour les instances nécessitant un accès Internet, la configuration de l'IGW (pour les sous-réseaux publics) ou de la passerelle NAT (pour les sous-réseaux privés) est critique.
Appairage VPC / Passerelle de transit : Si la connexion se fait entre des VPC, ces services de connectivité inter-VPC doivent être correctement configurés.

Diagnostic et résolution étape par étape

Commencez par le symptôme, puis suivez le chemin du paquet.

1. Vérifier l'état de l'instance et la connectivité réseau de base

Avant de plonger dans des configurations réseau complexes, assurez-vous que l'instance elle-même est en bonne santé et dispose des configurations réseau de base :

Vérifications d'état de l'instance : Dans la console EC2, sélectionnez l'instance et vérifiez l'onglet "Vérifications d'état". Les vérifications système et d'instance doivent réussir.
Adresses IP publiques et privées : Confirmez que l'instance a l'adresse que vous attendez. Une instance dans un sous-réseau public a toujours besoin d'une adresse IPv4 publique ou d'une IP élastique pour un accès Internet direct via IPv4.
Écouteur du système d'exploitation : Si le chemin réseau est ouvert mais que le port échoue toujours, confirmez que le service écoute sur l'instance. Par exemple, SSH doit écouter sur le port TCP 22 sauf si vous avez modifié la configuration du démon.
Résolution DNS : Si la connexion par IP fonctionne mais que la recherche par nom d'hôte échoue, vérifiez les paramètres DNS du VPC, les résolveurs personnalisés et /etc/resolv.conf sur Linux.

2. Examiner les groupes de sécurité

Les groupes de sécurité sont des pare-feu avec état qui contrôlent le trafic vers et depuis vos instances EC2. Ils sont une source très courante de problèmes de connectivité.

2.1. Règles entrantes

Si vous ne pouvez pas vous connecter à votre instance, par exemple SSH sur Linux ou RDP sur Windows :

Vérifiez le groupe de sécurité attaché à votre instance EC2.
Vérifiez les règles entrantes : Autorisez le port TCP requis depuis votre IP source ou un CIDR de confiance. Pour l'accès administrateur, préférez votre IP publique actuelle en tant que <votre_ip>/32 plutôt que 0.0.0.0/0.

Exemple : Pour autoriser l'accès SSH depuis votre adresse IP :

Type : SSH
Protocole : TCP
Plage de ports : 22
Source : <votre_ip>/32

2.2. Règles sortantes

Si votre instance ne peut pas atteindre des ressources externes (par exemple, télécharger des paquets, se connecter à d'autres services AWS) :

Vérifiez le groupe de sécurité attaché à votre instance EC2.
Vérifiez les règles sortantes : Par défaut, les groupes de sécurité autorisent tout le trafic sortant. Si des règles sortantes personnalisées ont été créées, assurez-vous qu'elles permettent le trafic nécessaire vers vos ports et IP de destination.

Exemple : Pour autoriser tout le trafic sortant :

Type : Tout le trafic
Protocole : Tout
Plage de ports : Tout
Destination : 0.0.0.0/0

3. Enquêter sur les listes de contrôle d'accès réseau (NACL)

Les NACL sont des pare-feu sans état qui opèrent au niveau du sous-réseau. Ils filtrent le trafic avant qu'il n'atteigne le groupe de sécurité ou l'instance.

Identifiez la NACL associée au sous-réseau de votre instance.
Vérifiez les règles entrantes : Les NACL sont évaluées dans l'ordre par numéro de règle. Assurez-vous qu'il existe une règle entrante qui autorise le trafic sur le port requis depuis l'IP source.
Vérifiez les règles sortantes : De même, vérifiez que les règles sortantes autorisent le trafic vers la destination.
Nature sans état : Les NACL ne se souviennent pas des connexions établies. Vous avez besoin de règles entrantes et sortantes pour les deux côtés du flux. Pour SSH depuis votre ordinateur portable, la NACL du sous-réseau a généralement besoin du port TCP 22 entrant depuis votre IP et des ports éphémères sortants vers votre IP pour le trafic de retour. Les plages de ports éphémères varient selon le système d'exploitation et le client, utilisez donc la plage appropriée à votre environnement.
Numérotation des règles : Les numéros de règle les plus bas sont évalués en premier. Utilisez des règles de refus explicites (par exemple, règle 100 pour refuser un trafic spécifique) et des règles d'autorisation (par exemple, règle 200 pour autoriser un trafic plus large) avec précaution.

4. Examiner les tables de routage

Les tables de routage déterminent où le trafic réseau est dirigé depuis vos sous-réseaux. Un routage incorrect peut empêcher le trafic d'atteindre sa destination.

Trouvez la table de routage associée au sous-réseau de votre instance.
Vérifiez la présence d'une route par défaut : Pour que les instances d'un sous-réseau public accèdent à Internet, il doit y avoir une route 0.0.0.0/0 pointant vers une passerelle Internet (IGW).
```
Destination | Cible
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | igw-xxxxxxxxxxxxxxxxx
```
Sous-réseaux privés et passerelles NAT : Pour que les instances d'un sous-réseau privé puissent initier des connexions Internet sortantes, la table de routage de ce sous-réseau a besoin d'une route 0.0.0.0/0 pointant vers une passerelle NAT ou une instance NAT.
```
Destination | Cible
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | nat-xxxxxxxxxxxxxxxxx
```
Appairage VPC, passerelle de transit ou VPN : Si votre instance doit communiquer avec un autre VPC ou un réseau sur site, ajoutez des routes pour les blocs CIDR distants vers la cible correcte des deux côtés où le routage est requis.

5. Dépanner la connectivité de la passerelle Internet (IGW) et de la passerelle NAT

Passerelle Internet

*   Assurez-vous que l'IGW est créée et attachée à votre VPC.
*   Vérifiez que la table de routage de votre sous-réseau public a une route `0.0.0.0/0` pointant vers l'IGW.
*   Confirmez que votre instance a une adresse IP publique ou une adresse IP élastique attribuée.
*   Les règles du groupe de sécurité et de la NACL doivent autoriser le trafic entrant et sortant requis. N'ouvrez pas les ports sensibles à tout Internet sauf si vous avez une raison claire et des contrôles compensateurs.

Passerelle NAT

*   Assurez-vous que la passerelle NAT est créée et se trouve dans un sous-réseau public.
*   Vérifiez que la passerelle NAT a une adresse IP élastique qui lui est associée.
*   Confirmez que la table de routage de votre sous-réseau privé a une route `0.0.0.0/0` pointant vers la passerelle NAT.
*   Les règles NACL sur les sous-réseaux privés et publics doivent autoriser la connexion sortante et le trafic de retour. Les passerelles NAT n'utilisent pas de groupes de sécurité.

6. Appairage VPC et passerelle de transit

Si vous rencontrez des problèmes de connectivité entre les VPC :

Appairage VPC :
- Assurez-vous que la connexion d'appairage est active et acceptée par les deux VPC.
- Vérifiez que les tables de routage dans les deux VPC ont des routes ajoutées pour autoriser le trafic vers les blocs CIDR du VPC appairé.
- Assurez-vous que les groupes de sécurité et les NACL dans les deux VPC autorisent le trafic entre les plages IP nécessaires.
Passerelle de transit :
- Confirmez que la passerelle de transit est créée et que les VPC concernés y sont attachés.
- Vérifiez les tables de routage de la passerelle de transit pour vous assurer qu'elles acheminent correctement le trafic entre les pièces jointes VPC.
- Vérifiez que les tables de routage dans chaque VPC ont également des routes pointant vers la passerelle de transit pour le trafic destiné à d'autres VPC.
- Les groupes de sécurité et les NACL dans chaque VPC doivent autoriser le trafic inter-VPC.

7. Utilisation des outils de vérification de la portée réseau AWS

AWS fournit des outils pour aider à diagnostiquer les problèmes réseau :

Analyseur de portée VPC : Cet outil analyse la portée entre les ressources source et destination prises en charge. Il peut identifier les échecs de chemin causés par les groupes de sécurité, les NACL, les tables de routage, les passerelles et la configuration réseau associée.
Journaux de flux VPC : Bien qu'ils ne diagnostiquent pas directement les échecs de connexion, les journaux de flux VPC capturent des informations sur le trafic IP entrant et sortant des interfaces réseau de votre VPC. L'analyse de ces journaux peut révéler des modèles de trafic bloqué ou inattendu, vous aidant à identifier les erreurs de configuration dans les groupes de sécurité ou les NACL.

8. Autres problèmes potentiels

Interface réseau élastique (ENI) : Assurez-vous que l'ENI est attachée à l'instance et configurée correctement.
Association de la table de routage du sous-réseau : Vérifiez que le sous-réseau est correctement associé à sa table de routage prévue.
Configuration DNS : Si vous utilisez un DNS personnalisé, assurez-vous qu'il résout correctement. Pour le DNS VPC par défaut, vérifiez si la résolution DNS est activée pour votre VPC.
Serveurs proxy : Si votre instance est configurée pour utiliser un proxy, assurez-vous que le proxy lui-même est accessible et configuré correctement.

Bonnes pratiques pour prévenir les problèmes de connectivité

Moindre privilège : Configurez les groupes de sécurité et les NACL avec les autorisations minimales nécessaires. Évitez d'utiliser 0.0.0.0/0 pour les ports sensibles sauf si absolument nécessaire et protégé par d'autres moyens.
Étiquetage : Étiquetez systématiquement vos ressources réseau (VPC, sous-réseaux, groupes de sécurité, tables de routage) pour identifier facilement leur objectif et les instances associées.
Documentation : Maintenez une documentation claire de votre topologie réseau, de vos schémas d'adressage IP et de vos règles de sécurité.
Audits réguliers : Examinez périodiquement vos règles de groupe de sécurité et de NACL pour vous assurer qu'elles sont toujours pertinentes et sécurisées.
Tirez parti des outils AWS : Familiarisez-vous avec l'analyseur de portée VPC et les journaux de flux VPC pour une surveillance proactive et un dépannage.

Conclusion

Lorsque la connectivité EC2 est interrompue, tracez le chemin dans l'ordre : santé de l'instance, écouteur, groupe de sécurité, NACL, table de routage, passerelle et règles du côté distant. Modifiez une couche à la fois, puis testez à nouveau. Cela permet de maintenir votre correctif ciblé et de rendre la prochaine panne beaucoup plus facile à diagnostiquer.