Dépannage Réseau VPC
Introduction
Le dépannage réseau est une compétence essentielle. Cette section vous apprend une méthode systématique pour diagnostiquer les problèmes de connectivité.
Méthode de Diagnostic
┌─────────────────────────────────────────────────────────────┐
│ MÉTHODE EN 5 ÉTAPES │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. IDENTIFIER LE SYMPTÔME │
│ └─► Quoi exactement ne fonctionne pas ? │
│ │
│ 2. VÉRIFIER LE CHEMIN │
│ └─► Par où doit passer le trafic ? │
│ │
│ 3. TESTER CHAQUE COMPOSANT │
│ └─► IGW → Route Table → NACL → SG → Instance │
│ │
│ 4. ANALYSER LES LOGS │
│ └─► VPC Flow Logs, CloudWatch │
│ │
│ 5. CORRIGER ET VALIDER │
│ └─► Appliquer le fix, tester à nouveau │
│ │
└─────────────────────────────────────────────────────────────┘
Checklist de Diagnostic
Problème : "Je ne peux pas atteindre mon instance depuis Internet"
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST ACCÈS INTERNET → INSTANCE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ☐ 1. L'instance a-t-elle une IP publique ou Elastic IP ? │
│ aws ec2 describe-instances --instance-id i-xxx │
│ → Vérifier "PublicIpAddress" │
│ │
│ ☐ 2. Le VPC a-t-il un Internet Gateway attaché ? │
│ aws ec2 describe-internet-gateways │
│ → Vérifier "Attachments" → "State: available" │
│ │
│ ☐ 3. La Route Table a-t-elle une route vers l'IGW ? │
│ aws ec2 describe-route-tables --route-table-id rtb-xxx │
│ → Vérifier : 0.0.0.0/0 → igw-xxx │
│ │
│ ☐ 4. La NACL autorise-t-elle le trafic ? │
│ aws ec2 describe-network-acls │
│ → Inbound ET Outbound (ports éphémères !) │
│ │
│ ☐ 5. Le Security Group autorise-t-il le port ? │
│ aws ec2 describe-security-groups --group-ids sg-xxx │
│ → Vérifier règle inbound pour le port │
│ │
│ ☐ 6. L'instance est-elle démarrée ? │
│ aws ec2 describe-instance-status --instance-id i-xxx │
│ → State: running, Status checks: passed │
│ │
│ ☐ 7. Le service écoute-t-il sur le bon port ? │
│ (Sur l'instance) netstat -tlnp | grep :80 │
│ → Service doit écouter sur 0.0.0.0:80 │
│ │
└─────────────────────────────────────────────────────────────┘
Problème : "Mon instance ne peut pas accéder à Internet"
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST INSTANCE → INTERNET │
├─────────────────────────────────────────────────────────────┤
│ │
│ CAS 1 : Instance dans Subnet PUBLIC │
│ ─────────────────────────────────── │
│ │
│ ☐ L'instance a-t-elle une IP publique ? │
│ ☐ Route 0.0.0.0/0 → igw-xxx existe ? │
│ ☐ SG outbound autorise le trafic ? │
│ ☐ NACL outbound autorise ? │
│ ☐ NACL inbound autorise réponses (ports éphémères) ? │
│ │
│ CAS 2 : Instance dans Subnet PRIVÉ │
│ ────────────────────────────────── │
│ │
│ ☐ NAT Gateway existe dans subnet public ? │
│ ☐ Route 0.0.0.0/0 → nat-xxx existe ? │
│ ☐ NAT Gateway est dans état "available" ? │
│ ☐ NAT Gateway a une Elastic IP ? │
│ ☐ SG outbound de l'instance autorise ? │
│ │
└─────────────────────────────────────────────────────────────┘
Problème : "Instances dans le même VPC ne communiquent pas"
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST COMMUNICATION INTRA-VPC │
├─────────────────────────────────────────────────────────────┤
│ │
│ ☐ 1. Les instances sont bien dans le même VPC ? │
│ │
│ ☐ 2. Route "local" existe ? (normalement automatique) │
│ 10.0.0.0/16 → local │
│ │
│ ☐ 3. Security Group SOURCE autorise-t-il ? │
│ Règle inbound : sg-destination ou CIDR subnet │
│ │
│ ☐ 4. Security Group DESTINATION autorise-t-il ? │
│ Règle inbound pour le port et la source │
│ │
│ ☐ 5. NACL des deux subnets autorisent ? │
│ (Vérifier les deux directions) │
│ │
│ ☐ 6. Utilisez-vous l'IP PRIVÉE ? │
│ Ne pas utiliser l'IP publique pour intra-VPC │
│ │
└─────────────────────────────────────────────────────────────┘
Scénarios de Dépannage
Scénario 1 : Timeout SSH
┌─────────────────────────────────────────────────────────────┐
│ SCÉNARIO : SSH TIMEOUT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Symptôme : ssh -i key.pem ec2-user@52.1.2.3 │
│ Connection timed out │
│ │
│ Diagnostic : │
│ │
│ 1. Ping l'IP publique │
│ $ ping 52.1.2.3 │
│ → Si timeout : problème avant l'instance │
│ │
│ 2. Vérifier le Security Group │
│ $ aws ec2 describe-security-groups --group-ids sg-xxx │
│ │
│ PROBLÈME TROUVÉ : │
│ ┌────────────────────────────────────────────┐ │
│ │ Inbound Rules : │ │
│ │ Type: SSH, Port: 22, Source: 10.0.0.0/16 │ │
│ │ │ │
│ │ ❌ Source limitée au VPC ! │ │
│ │ Votre IP publique n'est pas autorisée │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Solution : │
│ $ aws ec2 authorize-security-group-ingress \ │
│ --group-id sg-xxx \ │
│ --protocol tcp --port 22 \ │
│ --cidr VOTRE_IP/32 │
│ │
└─────────────────────────────────────────────────────────────┘
Scénario 2 : Site Web Inaccessible
┌─────────────────────────────────────────────────────────────┐
│ SCÉNARIO : HTTP 502 / TIMEOUT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Symptôme : curl http://52.1.2.3 → timeout │
│ │
│ Diagnostic : │
│ │
│ 1. Test port depuis votre machine │
│ $ nc -zv 52.1.2.3 80 │
│ → Si "Connection refused" = SG OK, service KO │
│ → Si "timeout" = SG ou routage KO │
│ │
│ 2. Vérifier Route Table │
│ $ aws ec2 describe-route-tables │
│ │
│ PROBLÈME TROUVÉ : │
│ ┌────────────────────────────────────────────┐ │
│ │ Routes : │ │
│ │ 10.0.0.0/16 → local │ │
│ │ │ │
│ │ ❌ Pas de route vers IGW ! │ │
│ │ Le subnet est PRIVÉ │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Solution : │
│ $ aws ec2 create-route \ │
│ --route-table-id rtb-xxx \ │
│ --destination-cidr-block 0.0.0.0/0 \ │
│ --gateway-id igw-xxx │
│ │
└─────────────────────────────────────────────────────────────┘
Scénario 3 : Application ne peut pas atteindre la DB
┌─────────────────────────────────────────────────────────────┐
│ SCÉNARIO : APP → DB TIMEOUT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Symptôme : Application error "Cannot connect to database" │
│ │
│ Configuration : │
│ • App server : 10.0.11.5 (sg-app) │
│ • DB server : 10.0.21.10 (sg-db) │
│ │
│ Diagnostic : │
│ │
│ 1. Depuis App server, tester la connexion │
│ $ nc -zv 10.0.21.10 3306 │
│ → timeout │
│ │
│ 2. Vérifier SG de la DB │
│ $ aws ec2 describe-security-groups --group-ids sg-db │
│ │
│ PROBLÈME TROUVÉ : │
│ ┌────────────────────────────────────────────┐ │
│ │ Inbound Rules : │ │
│ │ Type: MySQL, Port: 3306, Source: sg-web │ │
│ │ │ │
│ │ ❌ sg-app n'est pas autorisé ! │ │
│ │ Seul sg-web peut accéder │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Solution : │
│ $ aws ec2 authorize-security-group-ingress \ │
│ --group-id sg-db \ │
│ --protocol tcp --port 3306 \ │
│ --source-group sg-app │
│ │
└─────────────────────────────────────────────────────────────┘
VPC Flow Logs
Activer les Flow Logs
# Créer un log group CloudWatch
aws logs create-log-group --log-group-name /aws/vpc/flow-logs
# Activer Flow Logs sur le VPC
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-xxx \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name /aws/vpc/flow-logs \
--deliver-logs-permission-arn arn:aws:iam::xxx:role/flow-logs-role
Lire les Flow Logs
┌─────────────────────────────────────────────────────────────┐
│ FORMAT VPC FLOW LOGS │
├─────────────────────────────────────────────────────────────┤
│ │
│ version account-id interface-id srcaddr dstaddr │
│ srcport dstport protocol packets bytes start end │
│ action log-status │
│ │
│ Exemple : │
│ 2 123456789012 eni-abc123 10.0.1.5 52.1.2.3 │
│ 54321 443 6 10 5000 1234567890 1234567900 │
│ ACCEPT OK │
│ │
│ Interprétation : │
│ • Source : 10.0.1.5:54321 │
│ • Destination : 52.1.2.3:443 │
│ • Protocol : 6 (TCP) │
│ • Action : ACCEPT (autorisé) │
│ │
│ Actions possibles : │
│ • ACCEPT : Trafic autorisé │
│ • REJECT : Trafic bloqué par SG ou NACL │
│ │
└─────────────────────────────────────────────────────────────┘
Outils de Diagnostic
Commandes Utiles
# Vérifier l'état de l'instance
aws ec2 describe-instance-status --instance-id i-xxx
# Vérifier le Security Group attaché
aws ec2 describe-instances --instance-id i-xxx \
--query 'Reservations[].Instances[].SecurityGroups'
# Vérifier les règles d'un SG
aws ec2 describe-security-groups --group-ids sg-xxx
# Vérifier la Route Table d'un subnet
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=subnet-xxx"
# Vérifier la NACL d'un subnet
aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=subnet-xxx"
Tests Depuis l'Instance
# Test connectivité Internet
curl -I https://aws.amazon.com
# Test résolution DNS
nslookup google.com
# Test port spécifique
nc -zv IP_DESTINATION PORT
# Voir les routes
ip route
# Voir les connexions
netstat -tlnp
ss -tlnp
Tableau de Dépannage Rapide
| Symptôme | Cause Probable | Vérifier |
|---|---|---|
| Timeout depuis Internet | SG, Route, IGW | Checklist complète |
| Connection refused | Service non démarré | netstat, systemctl |
| Host unreachable | Route manquante | Route Table |
| Lent/Intermittent | NACL mal configuré | Règles NACL |
| Intra-VPC timeout | SG entre instances | Règles SG croisées |
Résumé
┌─────────────────────────────────────────────────────────────┐
│ RÉSUMÉ DÉPANNAGE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ORDRE DE VÉRIFICATION : │
│ │
│ 1. Instance running + status checks OK │
│ 2. IP publique présente (si accès Internet) │
│ 3. IGW attaché au VPC │
│ 4. Route 0.0.0.0/0 → igw (subnet public) │
│ 5. NACL autorise (+ ports éphémères) │
│ 6. Security Group autorise │
│ 7. Service écoute sur le port │
│ │
│ OUTILS : │
│ • aws ec2 describe-* (état des ressources) │
│ • VPC Flow Logs (analyse du trafic) │
│ • nc, curl, ping (tests de connectivité) │
│ │
└─────────────────────────────────────────────────────────────┘
Prochaine section : Lab : Dépannage VPC