But d'ICMP : le système de contrôle d'IP
ICMP (Internet Control Message Protocol) est le protocole de gestion et d'erreur de la suite IP. Défini dans la RFC 792 (IPv4) et la RFC 4443 (ICMPv6), il permet aux équipements réseau de signaler des problèmes et de tester la connectivité.
ICMP n'est pas un protocole de transport de données utilisateur — il ne transporte pas de sessions HTTP ou SSH. C'est le service de messagerie interne du réseau, utilisé par les routeurs, les hôtes et les outils de diagnostic.
Position dans le modèle
ICMP est encapsulé directement dans des paquets IP (protocole IP numéro 1). Il opère à la couche 3 (Réseau) et est étroitement lié à IP.
[En-tête Ethernet] [En-tête IP (proto=1)] [En-tête ICMP] [Données ICMP]
Structure d'un message ICMP
Tous les messages ICMP partagent un en-tête commun de 4 octets :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├───────────────────┬───────────────────┬─────────────────────────┤
│ Type (8 bits) │ Code (8 bits) │ Checksum (16 bits) │
├───────────────────┴───────────────────┴─────────────────────────┤
│ Données spécifiques au type/code │
└─────────────────────────────────────────────────────────────────┘
- Type : catégorie du message (ex: 8 = Echo Request, 0 = Echo Reply)
- Code : sous-type du message (ex: type 3 code 0 = Réseau inaccessible)
- Checksum : intégrité de l'en-tête ICMP
- Données : variable selon le type (identifiant, séquence, ou copie du paquet IP erroné)
Types ICMP principaux
Type 8 et 0 — Echo Request / Echo Reply (ping)
Le duo le plus connu. Un hôte envoie un Echo Request (type 8), l'hôte destination répond avec un Echo Reply (type 0). C'est la base de la commande ping.
Structure de l'Echo Request/Reply :
[Type][Code=0][Checksum][Identifier][Sequence Number][Données optionnelles]
Identifier : identifie l'instance de ping
Sequence : numéro de séquence (0, 1, 2, 3...)
Données : payload de remplissage (timestamp sur Linux)
Type 3 — Destination Unreachable
Le message le plus informatif pour le diagnostic. Envoyé quand un paquet ne peut pas être délivré.
| Type | Code | Signification |
|---|---|---|
| 3 | 0 | Network Unreachable — le réseau de destination est inconnu |
| 3 | 1 | Host Unreachable — l'hôte de destination est inconnu |
| 3 | 2 | Protocol Unreachable — le protocole n'est pas supporté |
| 3 | 3 | Port Unreachable — le port destination n'est pas ouvert (UDP) |
| 3 | 4 | Fragmentation Needed — paquet trop grand, DF bit activé (PMTU) |
| 3 | 5 | Source Route Failed — routage à la source échoué |
| 3 | 9 | Network Administratively Prohibited — filtré par un ACL |
| 3 | 10 | Host Administratively Prohibited — filtré par un ACL hôte |
| 3 | 13 | Communication Administratively Prohibited — filtré par pare-feu |
Type 3 Code 3 (Port Unreachable) est généré automatiquement par l'OS quand un datagramme UDP arrive sur un port sans application en écoute. C'est ainsi que traceroute (version UDP) détecte qu'il a atteint sa destination.
Type 11 — Time Exceeded
Envoyé par un routeur quand le TTL (Time To Live) d'un paquet atteint 0. C'est le mécanisme de base de traceroute.
| Type | Code | Signification |
|---|---|---|
| 11 | 0 | TTL Exceeded in Transit — paquet abandonné par un routeur |
| 11 | 1 | Fragment Reassembly Time Exceeded — timeout de réassemblage |
Type 5 — Redirect
Un routeur envoie ce message à un hôte pour lui signaler qu'il existe un meilleur chemin pour atteindre une destination. L'hôte devrait mettre à jour sa table de routage.
| Type | Code | Signification |
|---|---|---|
| 5 | 0 | Redirect for Network |
| 5 | 1 | Redirect for Host |
| 5 | 2 | Redirect for TOS and Network |
| 5 | 3 | Redirect for TOS and Host |
La commande ping
ping envoie des ICMP Echo Requests et mesure les temps de réponse.
Anatomie d'un ping
ping -c 5 google.com
# Sortie commentée :
# PING google.com (142.250.74.46) 56(84) bytes of data.
# └─ 56 octets de données, 84 octets total (56 + 8 ICMP + 20 IP)
#
# 64 bytes from par10s42-in-f14.1e100.net: icmp_seq=1 ttl=118 time=8.43 ms
# ↑ taille ↑ FQDN du répondant ↑ seq ↑ TTL ↑ RTT
#
# 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
# rtt min/avg/max/mdev = 8.127/8.563/9.123/0.342 ms
Paramètres ping utiles
# Envoyer 10 paquets
ping -c 10 8.8.8.8
# Fixer la taille des paquets (utile pour tester la MTU)
ping -s 1400 google.com # 1400 octets de données
# Intervalle entre paquets (par défaut 1 seconde)
ping -i 0.2 google.com # 200ms entre paquets (rapide)
# TTL personnalisé
ping -t 5 google.com # envoyer avec TTL=5
# Ping flood (root requis, à n'utiliser que dans un lab)
sudo ping -f 192.168.1.1 # le plus vite possible
# Interface source spécifique
ping -I eth0 8.8.8.8
# Ping IPv6
ping -6 ipv6.google.com
ping6 2001:4860:4860::8888
# Interpréter les résultats :
# 0% perte → connectivité parfaite
# Perte partielle → congestion ou lien instable
# 100% perte → hôte down, filtrage ICMP, ou route absente
# RTT très élevé → congestion ou long chemin
TTL et distance
Le TTL initial d'un paquet ICMP permet d'estimer l'OS distant :
| TTL reçu | TTL initial probable | OS probable |
|---|---|---|
| 64 | 64 | Linux, macOS, FreeBSD |
| 128 | 128 | Windows |
| 255 | 255 | Cisco IOS, appareils réseau |
| 54, 118... | 64 ou 128 | Déduit du nombre de sauts |
La commande traceroute
traceroute révèle le chemin emprunté par les paquets vers une destination, saut par saut (hop by hop).
Technique : le TTL incrémental
Envoi 1 : TTL=1 → Le 1er routeur le décrémente à 0 → ICMP Time Exceeded
→ On connaît l'IP du routeur 1
Envoi 2 : TTL=2 → Le 1er routeur le passe à TTL=1 → le 2e routeur → ICMP TE
→ On connaît l'IP du routeur 2
Envoi 3 : TTL=3 → ... → routeur 3 → ICMP Time Exceeded
→ On connaît l'IP du routeur 3
...jusqu'à la destination qui répond normalement
Utiliser traceroute
# traceroute standard (UDP sur Linux, ICMP sur Windows)
traceroute google.com
# Exemple de sortie :
# traceroute to google.com (142.250.74.46), 30 hops max, 60 byte packets
# 1 192.168.1.1 (192.168.1.1) 0.456 ms 0.412 ms 0.398 ms ← gateway
# 2 10.0.0.1 (10.0.0.1) 5.234 ms 5.189 ms 5.201 ms ← FAI
# 3 * * * ← filtré
# 4 212.27.32.1 (212.27.32.1) 8.123 ms 8.234 ms 8.111 ms
# 5 ...
# 12 142.250.74.46 (142.250.74.46) 12.456 ms 12.234 ms 12.345 ms ← destination
# Forcer ICMP (plus souvent autorisé par les pare-feux)
traceroute -I google.com
# Forcer TCP (contourne les pare-feux qui bloquent UDP/ICMP)
sudo traceroute -T -p 443 google.com
# Nombre de paquets par saut (par défaut 3)
traceroute -q 5 google.com
# Désactiver la résolution DNS inverse (plus rapide)
traceroute -n google.com
# Fixer le TTL de départ
traceroute -f 5 google.com # commence au saut 5
Interpréter les astérisques (* * *)
3 * * *
Les astérisques signifient que aucune réponse n'a été reçue dans le délai imparti. Cela peut signifier :
- Le routeur filtre les messages ICMP TTL Exceeded (courant sur les routeurs d'opérateur)
- Le routeur est très occupé et ne répond pas aux sondes traceroute
- Le chemin est asymétrique (les paquets retour passent par un autre chemin)
- Le routeur existe mais est configuré pour ne pas répondre
Ce n'est pas forcément une erreur : si les sauts suivants répondent, le chemin global fonctionne.
La commande mtr — My Traceroute
mtr combine ping et traceroute en un outil de monitoring continu. Il envoie des paquets en boucle et affiche les statistiques de perte et de latence pour chaque saut en temps réel.
Utiliser mtr
# Interface interactive en temps réel
mtr google.com
# Mode non-interactif, 100 paquets par saut, puis rapport
mtr -n --report --report-cycles 100 google.com
# Exemple de rapport :
# HOST: myserver Loss% Snt Last Avg Best Wrst StDev
# 1. 192.168.1.1 0.0% 100 0.4 0.4 0.3 0.8 0.1
# 2. 10.0.0.1 0.0% 100 4.9 5.1 4.7 7.2 0.3
# 3. ??? 100.0% 100 0.0 0.0 0.0 0.0 0.0 ← filtré
# 4. 212.27.32.1 0.0% 100 8.1 8.2 7.9 9.1 0.2
# 12. 142.250.74.46 0.0% 100 12.3 12.4 12.0 14.1 0.4
# Colonnes :
# Loss% : % de paquets perdus sur ce saut
# Snt : nombre de paquets envoyés
# Last : RTT dernier paquet
# Avg : RTT moyen
# Best : RTT minimum
# Wrst : RTT maximum
# StDev : écart-type (stabilité)
# Forcer ICMP (root requis)
sudo mtr --icmp google.com
# Forcer TCP sur port 443
sudo mtr --tcp --port 443 google.com
Interpréter les résultats mtr
| Observation | Interprétation |
|---|---|
| Perte 100% sur un saut, 0% sur les suivants | Routeur filtre ICMP, pas une vraie perte |
| Perte progressive à partir d'un saut | Congestion ou problème sur ce lien |
| RTT soudainement élevé à un saut | Latence sur ce lien (satellite, sous-marin) |
| RTT fluctuant (StDev élevé) | Jitter = problème pour VoIP/vidéo |
| ??? (pas de réponse) | Routeur silencieux, pas forcément mort |
ICMPv6 et NDP
ICMPv6 (RFC 4443) est beaucoup plus riche qu'ICMPv4. En plus des fonctions diagnostiques classiques, il gère des fonctions vitales pour IPv6 que l'ARP gérait en IPv4.
Types ICMPv6 supplémentaires
| Type | Nom | Rôle |
|---|---|---|
| 1 | Destination Unreachable | Inaccessibilité (comme ICMPv4 type 3) |
| 2 | Packet Too Big | PMTU discovery (comme ICMPv4 type 3 code 4) |
| 3 | Time Exceeded | TTL épuisé (comme ICMPv4 type 11) |
| 128 | Echo Request | Ping IPv6 |
| 129 | Echo Reply | Pong IPv6 |
| 133 | Router Solicitation | NDP : cherche routeurs |
| 134 | Router Advertisement | NDP : annonce routeur + préfixe |
| 135 | Neighbor Solicitation | NDP : remplace ARP Request |
| 136 | Neighbor Advertisement | NDP : remplace ARP Reply |
| 137 | Redirect | Meilleur chemin disponible |
NDP en pratique
# Table de voisins IPv6 (équivalent ARP)
ip -6 neigh show
# Ping IPv6 (utilise ICMPv6 type 128/129)
ping6 google.com
# Observer les messages NDP (Router Advertisement)
sudo tcpdump -i eth0 icmp6 -n -v
# Capturer spécifiquement les NDP Neighbor Solicitation
sudo tcpdump -i eth0 "icmp6 and ip6[40] == 135"
# Voir les Router Advertisements reçus
sudo rdisc6 eth0 # (package ndisc6)
PMTU Discovery — Path MTU Discovery
La PMTU Discovery (RFC 1191) est le mécanisme par lequel une connexion TCP/IP découvre dynamiquement la MTU maximale sur le chemin vers la destination, afin d'éviter la fragmentation.
Fonctionnement
1. L'émetteur envoie un grand paquet avec bit DF (Don't Fragment) activé
2. Si le paquet est trop grand pour un routeur sur le chemin :
→ Le routeur DROP le paquet
→ Envoie ICMP Type 3 Code 4 "Fragmentation Needed" avec la MTU du lien
3. L'émetteur réduit sa taille de paquet et réessaie
4. Le processus continue jusqu'à trouver la MTU optimale
Problème : ICMP Black Holes
Si un pare-feu bloque tous les ICMP, les messages "Fragmentation Needed" sont droppés. L'émetteur ne sait pas qu'il doit réduire la taille de ses paquets. La connexion TCP s'établit (le handshake utilise de petits paquets), mais dès qu'une grande quantité de données est envoyée, la connexion se bloque mystérieusement. C'est l'ICMP Black Hole.
# Tester la MTU du chemin vers une destination
ping -M do -s 1400 google.com
# -M do : activer le bit DF (Don't Fragment)
# -s 1400 : taille des données (+ 28 octets IP+ICMP = 1428 total)
# Si la réponse est "Frag needed and DF set" → la MTU est < 1428
# Trouver la MTU exacte par dichotomie
ping -M do -s 1472 google.com # MTU Ethernet standard (1472 + 28 = 1500)
ping -M do -s 1450 google.com
ping -M do -s 1400 google.com
# → identifier la taille max qui passe
Pourquoi bloquer tout ICMP est une mauvaise idée
Un mythe répandu en sécurité : "Bloquer tout ICMP améliore la sécurité." C'est faux et dangereux.
Ce que vous cassez en bloquant tout ICMP
| ICMP bloqué | Conséquence |
|---|---|
| Type 3 Code 4 (Fragmentation Needed) | PMTU Black Holes, connexions TCP qui bloquent |
| Type 3 Code 0/1 (Unreachable) | Les applications ne savent pas que la destination est morte |
| Type 11 (TTL Exceeded) | traceroute ne fonctionne plus |
| Type 0/8 (Echo) | ping ne fonctionne plus |
La bonne approche : filtrage sélectif ICMP
# Autoriser uniquement les ICMP nécessaires avec iptables
# Autoriser l'Echo Request entrant (ping vers le serveur)
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
# Autoriser l'Echo Reply sortant
sudo iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT
# CRITIQUE : autoriser les messages d'erreur ICMP (ne jamais bloquer)
sudo iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
# Bloquer le reste (ex: timestamp, address mask)
sudo iptables -A INPUT -p icmp -j DROP
Session pratique de diagnostic réseau
Scénario : un serveur web est injoignable
# Étape 1 : le serveur répond-il au ping ? (couche 3)
ping -c 3 192.168.1.100
# → No route to host : problème de routage
# → Timeout (100% perte) : hôte down ou ICMP bloqué
# → Réponse ok : continuer à l'étape 2
# Étape 2 : quel chemin les paquets empruntent-ils ?
mtr --report -c 20 192.168.1.100
# → Identifier où la perte commence
# Étape 3 : le port web est-il ouvert ? (couche 4)
nc -zv -w 3 192.168.1.100 80
# → Connection refused : service arrêté
# → Timeout : pare-feu bloque
# → Connected : service accessible
# Étape 4 : le service répond-il correctement ? (couche 7)
curl -v --max-time 5 http://192.168.1.100/
# → HTTP 200 OK : tout fonctionne
# → HTTP 502 Bad Gateway : backend problème
# → SSL error : certificat ou TLS
# Étape 5 : capturer le trafic
sudo tcpdump -i eth0 host 192.168.1.100 and tcp port 80 -n
# Étape 6 : vérifier les logs côté serveur
tail -f /var/log/nginx/error.log
journalctl -u nginx -n 50
Récapitulatif des outils ICMP
| Outil | Usage | Protocole |
|---|---|---|
ping |
Test de connectivité, latence | ICMP type 8/0 |
ping6 |
Test IPv6 | ICMPv6 type 128/129 |
traceroute |
Chemin de routage | ICMP type 11 + 3 |
mtr |
Combiné ping+traceroute, stats | ICMP type 11 + 3 |
tcpdump -i eth0 icmp |
Capturer trafic ICMP | — |
nping --icmp |
Génération ICMP avancée | ICMP |
Passez au chapitre final : DNS : l'annuaire d'Internet — comment les noms de domaine sont traduits en adresses IP.