Lab : Dépannage VPC
Objectif du Lab
Ce lab vous met dans la peau d'un administrateur cloud qui doit diagnostiquer et résoudre des problèmes de connectivité réseau. Vous analyserez des scénarios réels et proposerez des solutions.
Ce lab est basé sur l'analyse de scénarios. Vous devez identifier le problème et proposer la solution avant de regarder la réponse.
Partie 1 : Cas d'Étude
Architecture de Référence
Toutes les questions se basent sur cette architecture :
┌─────────────────────────────────────────────────────────────────────────┐
│ ARCHITECTURE E-COMMERCE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ INTERNET │
│ │ │
│ ┌──────▼──────┐ │
│ │ IGW │ │
│ │ igw-abc123 │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────────────────────────────┼──────────────────────────────┐ │
│ │ VPC │ (10.0.0.0/16) │ │
│ │ │ │ │
│ │ ┌──────────────────────────┴────────────────────────────┐ │ │
│ │ │ SUBNET PUBLIC │ │ │
│ │ │ 10.0.1.0/24 │ │ │
│ │ │ rtb-public │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │
│ │ │ │ BASTION │ │ NAT Gateway │ │ │ │
│ │ │ │ 10.0.1.10 │ │ 10.0.1.50 │ │ │ │
│ │ │ │ sg-bastion │ │ nat-xyz789 │ │ │ │
│ │ │ │ IP: 52.1.2.3 │ │ EIP: 52.4.5.6 │ │ │ │
│ │ │ └─────────────────┘ └─────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────────┐ │ │
│ │ │ SUBNET PRIVÉ APP │ │ │
│ │ │ 10.0.11.0/24 │ │ │
│ │ │ rtb-private │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │
│ │ │ │ WEB SERVER │ │ API SERVER │ │ │ │
│ │ │ │ 10.0.11.20 │ │ 10.0.11.30 │ │ │ │
│ │ │ │ sg-web │ │ sg-api │ │ │ │
│ │ │ └─────────────────┘ └─────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────────┐ │ │
│ │ │ SUBNET PRIVÉ DB │ │ │
│ │ │ 10.0.21.0/24 │ │ │
│ │ │ rtb-database │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ │ │ │
│ │ │ │ DATABASE │ │ │ │
│ │ │ │ 10.0.21.10 │ │ │ │
│ │ │ │ sg-database │ │ │ │
│ │ │ │ MySQL:3306 │ │ │ │
│ │ │ └─────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────┘
Configuration Actuelle
Route Tables :
rtb-public:
┌─────────────────────┬───────────────┐
│ Destination │ Target │
├─────────────────────┼───────────────┤
│ 10.0.0.0/16 │ local │
│ 0.0.0.0/0 │ igw-abc123 │
└─────────────────────┴───────────────┘
rtb-private:
┌─────────────────────┬───────────────┐
│ Destination │ Target │
├─────────────────────┼───────────────┤
│ 10.0.0.0/16 │ local │
│ 0.0.0.0/0 │ nat-xyz789 │
└─────────────────────┴───────────────┘
rtb-database:
┌─────────────────────┬───────────────┐
│ Destination │ Target │
├─────────────────────┼───────────────┤
│ 10.0.0.0/16 │ local │
└─────────────────────┴───────────────┘
Security Groups :
sg-bastion:
┌────────────────────────────────────────────────────┐
│ Inbound: SSH (22) from 0.0.0.0/0 │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
sg-web:
┌────────────────────────────────────────────────────┐
│ Inbound: HTTP (80) from 0.0.0.0/0 │
│ Inbound: SSH (22) from sg-bastion │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
sg-api:
┌────────────────────────────────────────────────────┐
│ Inbound: TCP (8080) from sg-web │
│ Inbound: SSH (22) from sg-bastion │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
sg-database:
┌────────────────────────────────────────────────────┐
│ Inbound: MySQL (3306) from sg-api │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
Partie 2 : Exercices de Dépannage
Exercice 1 : SSH vers le Bastion
Symptôme : Un administrateur ne peut pas se connecter en SSH au bastion depuis son bureau (IP: 203.0.113.50).
$ ssh -i key.pem ec2-user@52.1.2.3
Connection timed out
Questions :
- Quel est le problème le plus probable ?
- Quelle commande utiliseriez-vous pour vérifier ?
- Quelle est la solution ?
💡 Solution Exercice 1
Analyse :
Le Security Group sg-bastion autorise SSH depuis 0.0.0.0/0, donc ce n'est pas ça.
Vérifions :
- ✅ Route Table rtb-public a une route vers IGW
- ✅ IGW est attaché
- ❓ Le bastion a-t-il une IP publique ?
Vérification :
aws ec2 describe-instances --instance-id i-bastion \
--query 'Reservations[].Instances[].PublicIpAddress'
Problème probable : Le bastion n'a pas d'IP publique ou l'IP a changé après un redémarrage.
Solution :
# Option 1 : Associer une Elastic IP
aws ec2 allocate-address --domain vpc
aws ec2 associate-address --instance-id i-bastion --allocation-id eipalloc-xxx
# Option 2 : Activer l'auto-assign public IP sur le subnet
Exercice 2 : Web Server Inaccessible
Symptôme : Le site web n'est pas accessible depuis Internet.
$ curl http://10.0.11.20
curl: (7) Failed to connect to 10.0.11.20 port 80: No route to host
Questions :
- Pourquoi l'admin utilise-t-il l'IP privée depuis Internet ?
- Quel est le vrai problème d'architecture ici ?
- Comment devrait être configurée l'architecture ?
💡 Solution Exercice 2
Analyse :
Le Web Server est dans un subnet privé (10.0.11.0/24) !
Problèmes identifiés :
- L'admin essaie d'accéder à une IP privée depuis Internet (impossible)
- Le web server n'a pas d'IP publique
- Même avec une IP publique, pas de route IGW sur ce subnet
Architecture incorrecte : Un serveur web destiné au public ne devrait pas être dans un subnet privé.
Solutions possibles :
Option A (Recommandée) : Ajouter un Load Balancer
Internet → ALB (subnet public) → Web Server (subnet privé)
Option B : Déplacer le Web Server dans subnet public
Internet → IGW → Web Server (subnet public avec IP publique)
Pour Option A :
- Créer un Application Load Balancer dans le subnet public
- Configurer un Target Group avec le web server
- Mettre à jour sg-web pour accepter le trafic depuis sg-alb
Exercice 3 : API ne peut pas accéder à la Database
Symptôme : L'API server ne peut pas se connecter à MySQL.
$ mysql -h 10.0.21.10 -u app -p
ERROR 2003 (HY000): Can't connect to MySQL server on '10.0.21.10' (110)
Questions :
- Listez toutes les causes possibles.
- Comment vérifier chaque hypothèse ?
- Quelle est la cause la plus probable vu la configuration ?
💡 Solution Exercice 3
Hypothèses et vérifications :
| Hypothèse | Vérification | Résultat |
|---|---|---|
| SG API → DB | sg-database autorise sg-api ? | ❌ Autorise sg-api |
| Route | Route local existe ? | ✅ Oui (10.0.0.0/16 → local) |
| MySQL running | Service MySQL démarré ? | À vérifier |
| Port listening | MySQL écoute sur 0.0.0.0:3306 ? | À vérifier |
Problème identifié :
En regardant sg-database :
Inbound: MySQL (3306) from sg-api
C'est correct. Mais regardons sg-api :
Inbound: TCP (8080) from sg-web
Le sg-api n'a pas d'accès sortant explicite vers MySQL ? Non, il a Outbound: All traffic donc c'est OK.
Vérification plus poussée : L'API server est-il bien dans sg-api ?
aws ec2 describe-instances --filters "Name=private-ip-address,Values=10.0.11.30" \
--query 'Reservations[].Instances[].SecurityGroups'
Cause probable : L'API server n'est peut-être pas attaché au bon Security Group !
Exercice 4 : Web Server ne peut pas installer de packages
Symptôme : Le web server ne peut pas faire yum update.
$ sudo yum update
Loaded plugins: priorities, update-motd, upgrade-helper
Could not retrieve mirrorlist https://... error was
12: Timeout on ...
Questions :
- Pourquoi le serveur ne peut-il pas accéder à Internet ?
- Vérifiez la configuration réseau.
- Proposez la solution.
💡 Solution Exercice 4
Analyse :
Le Web Server est dans le subnet privé (10.0.11.0/24) qui utilise rtb-private.
rtb-private :
10.0.0.0/16 → local
0.0.0.0/0 → nat-xyz789
La route vers NAT Gateway existe ! Vérifions :
Checklist NAT Gateway :
- NAT Gateway dans état "available" ?
aws ec2 describe-nat-gateways --nat-gateway-ids nat-xyz789
-
NAT Gateway dans un subnet avec IGW ?
- NAT est dans 10.0.1.0/24 (public) ✅
-
NAT Gateway a une Elastic IP ?
- EIP: 52.4.5.6 ✅
-
Le subnet public a la route vers IGW ?
- 0.0.0.0/0 → igw-abc123 ✅
Si tout est OK côté NAT, vérifier :
-
Security Group du NAT Gateway ?
- NAT Gateway n'a pas de SG (c'est un service managé)
-
NACL du subnet privé autorise la sortie ?
Cause probable : NACL restrictif sur le subnet privé qui bloque le trafic sortant ou les ports éphémères entrants.
Solution :
# Vérifier la NACL
aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=subnet-private"
# S'assurer que les règles autorisent :
# Outbound: 0.0.0.0/0 (all traffic)
# Inbound: ports éphémères 1024-65535 (pour les réponses)
Exercice 5 : Database ne reçoit pas de connexions
Symptôme : Après avoir corrigé l'exercice 3, la DB log montre 0 connexions.
Configuration supplémentaire révélée :
NACL du subnet database (acl-db):
┌────────┬──────────┬───────────┬─────────────┬────────┐
│ Rule # │ Type │ Port │ Source/Dest │ Action │
├────────┼──────────┼───────────┼─────────────┼────────┤
│ 100 │ Inbound │ 3306 │ 10.0.1.0/24 │ ALLOW │
│ * │ Inbound │ All │ 0.0.0.0/0 │ DENY │
├────────┼──────────┼───────────┼─────────────┼────────┤
│ 100 │ Outbound │ 1024-65535│ 10.0.1.0/24 │ ALLOW │
│ * │ Outbound │ All │ 0.0.0.0/0 │ DENY │
└────────┴──────────┴───────────┴─────────────┴────────┘
Questions :
- Quel est le problème avec cette NACL ?
- Pourquoi les connexions de l'API sont bloquées ?
- Corrigez la NACL.
💡 Solution Exercice 5
Problème :
La NACL autorise le trafic MySQL (3306) seulement depuis 10.0.1.0/24 (subnet public).
Mais l'API server est dans 10.0.11.0/24 (subnet privé app) !
Rule 100 Inbound: 3306 from 10.0.1.0/24 → N'inclut pas 10.0.11.0/24
Solution :
# Ajouter une règle pour le subnet app
aws ec2 create-network-acl-entry \
--network-acl-id acl-db \
--rule-number 110 \
--protocol tcp \
--port-range From=3306,To=3306 \
--cidr-block 10.0.11.0/24 \
--rule-action allow \
--ingress
# Ajouter la règle outbound correspondante
aws ec2 create-network-acl-entry \
--network-acl-id acl-db \
--rule-number 110 \
--protocol tcp \
--port-range From=1024,To=65535 \
--cidr-block 10.0.11.0/24 \
--rule-action allow \
--egress
Leçon : Les NACL sont stateless et très précises sur les sources/destinations.
Partie 3 : Exercice de Synthèse
Votre Mission
Documentez une procédure de dépannage complète pour votre équipe.
Créez un document avec :
-
Flowchart de diagnostic : Arbre de décision pour les problèmes courants
-
Commandes de vérification : Liste des commandes AWS CLI essentielles
-
Checklist rapide : Liste à cocher pour chaque type de problème
-
Leçons apprises : Erreurs communes et comment les éviter
Template de Livrable
# Procédure de Dépannage Réseau VPC
## 1. Flowchart de Diagnostic
[Insérer votre diagramme]
## 2. Commandes de Vérification
### État des instances
```bash
[Vos commandes]
Security Groups
[Vos commandes]
Routes
[Vos commandes]
3. Checklist par Symptôme
Timeout depuis Internet
- ...
- ...
Timeout vers Internet
- ...
- ...
4. Leçons Apprises
| Erreur Commune | Comment Éviter |
|---|---|
| ... | ... |
## Critères d'Évaluation
| Critère | Points |
|---------|--------|
| Exercices 1-5 correctement analysés | /50 |
| Flowchart clair et complet | /15 |
| Commandes pertinentes | /15 |
| Checklist utilisable | /10 |
| Leçons apprises pertinentes | /10 |
| **Total** | **/100** |
---
*Prochaine semaine : [Publication Web](../module_07/index.mdx)*