ICMP — Le protocole de diagnostic réseau

Votre ping ne répond pas et vous ne savez pas pourquoi ? ICMP est le protocole qui vous donne les indices pour comprendre ce qui se passe. Ce module vous apprend à lire les messages d’erreur ICMP et à les utiliser pour diagnostiquer vos problèmes de connectivité réseau.

TL;DR — L’essentiel en 30 secondes

• ICMP = protocole de diagnostic (ping, traceroute)
• Timeout = pas de réponse (filtré ou machine down)
• Destination Unreachable = réponse explicite (réseau, hôte ou port inaccessible)
• Ping bloqué ≠ machine down : testez avec nc sur le port applicatif

Je sais que c’est bon si…

• ping -c 2 8.8.8.8 fonctionne (ou je comprends pourquoi il est bloqué)
• Je sais distinguer timeout de “Destination Unreachable”
• Si ping échoue, je teste avec nc -zv hôte port

Commandes minimales à retenir

# 1. Test de base
ping -c 3 google.com

# 2. Traceroute (voir le chemin)
traceroute -n google.com

# 3. Si ping bloqué, tester le port applicatif
nc -zv serveur 22

ping peut être bloqué — ce n'est pas un bug

Dans le cloud (AWS, GCP, Azure) et en entreprise, ICMP est souvent filtré par défaut. Un ping qui ne répond pas ne signifie pas que la machine est down.

Utilisez nc -zv ou curl pour tester les ports applicatifs.

Prérequis

• Module 4 complété : vous comprenez le routage et traceroute
• Module 5 complété : vous connaissez TCP et UDP
• Une machine Linux avec accès réseau

ICMP : le messager silencieux

Vous utilisez ICMP tous les jours sans le savoir : chaque ping et chaque traceroute s’appuient dessus. C’est le protocole qui informe qu’un problème s’est produit sur le réseau.

Si ping: Operation not permitted

Sur certains systèmes durcis, ping peut nécessiter des privilèges. Diagnostic :

getcap $(which ping)

Si vide, ping n’a pas la capability cap_net_raw. Solution (selon votre politique sécu) :

sudo setcap cap_net_raw+ep $(which ping)

Préférez la capability au setuid root pour limiter la surface d’attaque.

Ce que vous allez apprendre

• Ce qu’est ICMP : le protocole de contrôle et d’erreur d’Internet
• Echo Request/Reply : comment fonctionne ping
• Les messages d’erreur : Destination Unreachable, TTL Exceeded
• Interpréter les codes : pourquoi le réseau, l’hôte ou le port est inaccessible
• ICMP et les pare-feu : pourquoi ping peut être bloqué
• Diagnostic pratique : utiliser ICMP pour trouver la cause d’un problème

Qu’est-ce que ICMP ?

ICMP (Internet Control Message Protocol) est un protocole de diagnostic et de signalisation. Contrairement à TCP et UDP qui transportent des données applicatives, ICMP transporte des messages de contrôle :

• “Ta destination est injoignable”
• “Le paquet a fait trop de sauts”
• “Ton paquet est trop gros”
• “Es-tu vivant ?” (ping)

Protocole	Rôle	Exemple d’usage
TCP	Transport fiable	HTTP, SSH
UDP	Transport rapide	DNS, VoIP
ICMP	Diagnostic et erreurs	ping, traceroute

Glissez pour voir

ICMP n'est pas TCP ni UDP

ICMP est un protocole de couche réseau (comme IP), pas de couche transport. Il n’a pas de notion de port — juste des types et des codes qui identifient le message.

Comment fonctionne ping (Echo Request/Reply)

La commande ping envoie un message ICMP Echo Request et attend un Echo Reply :

Le processus en détail

1. Votre machine envoie un Echo Request

   Type ICMP : 8 (Echo Request)

   Le paquet contient un identifiant et un numéro de séquence pour matcher les réponses.

2. La destination reçoit et répond

   Type ICMP : 0 (Echo Reply)

   La machine cible renvoie le même contenu, ce qui permet de calculer le temps aller-retour (RTT).

3. Votre machine affiche le résultat

   64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms

   • icmp_seq : numéro de séquence
   • ttl : nombre de sauts restants
   • time : temps aller-retour

Interpréter la sortie de ping

ping -c 4 google.com

PING google.com (142.250.185.46) 56(84) bytes of data.
64 bytes from par21s17-in-f14.1e100.net (142.250.185.46): icmp_seq=1 ttl=117 time=11.2 ms
64 bytes from par21s17-in-f14.1e100.net (142.250.185.46): icmp_seq=2 ttl=117 time=10.8 ms
64 bytes from par21s17-in-f14.1e100.net (142.250.185.46): icmp_seq=3 ttl=117 time=11.1 ms
64 bytes from par21s17-in-f14.1e100.net (142.250.185.46): icmp_seq=4 ttl=117 time=10.9 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 10.823/10.991/11.184/0.136 ms

Les sorties varient

L’IP de google.com change (anycast, load-balancing), le hostname reverse et le TTL aussi. Certains réseaux filtrent ICMP. On interprète surtout les patterns (reply / unreachable / timeout), pas les valeurs exactes.

Élément	Signification
64 bytes	Taille du paquet reçu
icmp_seq=1	Premier paquet de la séquence
ttl=117	Marge restante avant expiration du paquet
time=11.2 ms	Latence aller-retour
0% packet loss	Aucun paquet perdu
rtt min/avg/max	Statistiques de latence

Glissez pour voir

TTL et nombre de sauts

Le ttl affiché est le TTL restant à l’arrivée. Pour estimer le nombre de sauts, il faudrait connaître le TTL initial de la machine distante (souvent 64, 128 ou 255 selon l’OS, mais non garanti). Un TTL faible suggère un chemin long, mais ne permet pas de compter précisément les routeurs traversés.

Les messages d’erreur ICMP

ICMP ne sert pas qu’à ping. Il signale les erreurs quand un paquet ne peut pas atteindre sa destination :

Types ICMP les plus courants

Type	Nom	Signification
0	Echo Reply	Réponse à un ping
3	Destination Unreachable	La destination ne peut pas être atteinte
8	Echo Request	Demande de ping
11	Time Exceeded	TTL expiré (utilisé par traceroute)

Glissez pour voir

Destination Unreachable (Type 3) : les codes importants

Le Type 3 a plusieurs codes qui précisent la raison de l’échec :

Code	Message	Signification	Cause probable
0	Network Unreachable	Pas de route vers ce réseau	Routage cassé, réseau inexistant
1	Host Unreachable	Machine injoignable	Machine éteinte, ARP échoué
3	Port Unreachable	Pas de service sur ce port (UDP)	Service non démarré
4	Fragmentation Needed	Paquet trop gros, DF set	MTU trop petit sur le chemin
13	Administratively Prohibited	Bloqué par un pare-feu	Règle firewall

Glissez pour voir

Code 4 : critique pour PMTUD

Fragmentation Needed and DF set (Type 3, Code 4) est utilisé par Path MTU Discovery (RFC 1191). Si vous bloquez ce message ICMP, vous provoquez des pannes fantômes :

• TLS handshake qui freeze
• Gros POST/PUT qui timeout
• VPN et tunnels qui dysfonctionnent

Ne jamais bloquer ICMP Type 3 Code 4 (ni ICMPv6 Packet Too Big).

Port Unreachable = UDP uniquement (Type 3 / Code 3)

Le code 3 “Port Unreachable” (ICMPv4 Type 3, Code 3 selon RFC 792) ne concerne que UDP. Pour TCP, l’indication d’un port fermé est un paquet RST (Reset), pas un message ICMP.

C’est pourquoi nc -zv sur un port TCP fermé affiche “Connection refused” (RST reçu), pas un message ICMP.

Time Exceeded (Type 11) : comment fonctionne traceroute

Chaque paquet IP a un TTL (Time To Live) qui est décrémenté à chaque routeur. Quand le TTL atteint 0, le routeur jette le paquet et envoie un message ICMP Type 11 “Time Exceeded” (IANA ICMP Parameters).

Traceroute exploite ce mécanisme :

1. Envoie un paquet avec TTL=1

   Le premier routeur décrémente TTL à 0 et renvoie ICMP “Time Exceeded”. On connaît le premier saut.

2. Envoie un paquet avec TTL=2

   Le deuxième routeur renvoie “Time Exceeded”. On connaît le deuxième saut.

3. Continue jusqu’à la destination

   Quand la destination est atteinte, traceroute reçoit soit un Echo Reply (si probes ICMP), soit ICMP Port Unreachable (si probes UDP vers un port élevé non écouté).

Probes : UDP, ICMP ou TCP ?

Sur Linux/Unix, traceroute envoie par défaut des probes UDP vers des ports élevés (33434+). Les réponses intermédiaires sont toujours ICMP (Time Exceeded), et la fin est signalée par ICMP Port Unreachable.

Commande	Probes envoyées	Quand l’utiliser
traceroute	UDP (défaut)	Cas général
traceroute -I	ICMP Echo Request	Quand UDP est filtré
traceroute -T -p 443	TCP SYN	Quand ICMP et UDP sont filtrés

Glissez pour voir

traceroute google.com

traceroute to google.com (142.250.185.46), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.543 ms  0.512 ms  0.503 ms
 2  10.0.0.1 (10.0.0.1)  8.234 ms  8.219 ms  8.205 ms
 3  * * *
 4  72.14.215.85 (72.14.215.85)  11.234 ms  11.219 ms  11.205 ms
 5  142.250.185.46 (142.250.185.46)  10.823 ms  10.808 ms  10.794 ms

Sortie	Signification
_gateway	Nom DNS du routeur (si disponible)
0.543 ms	Temps de réponse (3 tentatives)
* * *	Pas de réponse (ICMP bloqué ou timeout)

Glissez pour voir

Quand ping échoue : interpréter les résultats

Cas 1 : Timeout (pas de réponse)

ping 10.0.0.99

PING 10.0.0.99 (10.0.0.99) 56(84) bytes of data.
--- 10.0.0.99 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3062ms

Causes possibles :

• Machine éteinte ou inexistante
• Pare-feu qui DROP les paquets (sans répondre)
• Problème de routage (paquets perdus)

Cas 2 : Destination Host Unreachable

ping 192.168.99.1

From 192.168.1.1 icmp_seq=1 Destination Host Unreachable

Cause : Émis par la passerelle ou un nœud intermédiaire qui ne peut pas joindre l’hôte final (ARP échoué, machine éteinte, voisinage L2 injoignable). Notez l’IP source du message (ici 192.168.1.1) : c’est elle qui a généré l’erreur.

Cas 3 : Network Unreachable

ping 10.99.0.1

connect: Network is unreachable

Cause : Votre machine ou un routeur intermédiaire n’a pas de route vers ce réseau.

Cas 4 : Administratively Prohibited

ping 192.168.1.100

From 192.168.1.1: icmp_seq=1 Packet filtered

Cause : Un pare-feu a explicitement rejeté le paquet avec un message ICMP.

ICMP et les pare-feu : une relation compliquée

Les pare-feu peuvent bloquer ou limiter ICMP de plusieurs façons :

Comportement pare-feu	Résultat ping	Sécurité
ICMP autorisé	Réponse normale	Faible (expose la machine)
ICMP DROP	Timeout	Moyen (machine invisible)
ICMP REJECT	”Administratively Prohibited”	Moyen (on sait qu’il y a un FW)
Rate limit	Certains pings répondent	Bon compromis

Glissez pour voir

Ping bloqué ≠ machine inaccessible

Ne jamais conclure qu’une machine est down parce que ping ne répond pas !

De nombreux serveurs (surtout dans le cloud) bloquent ICMP par défaut. Utilisez d’autres méthodes :

# Tester si le port TCP répond
nc -zv 192.168.1.100 22

# Tester si le port HTTP répond
curl -I http://192.168.1.100

Bonnes pratiques pour les pare-feu

Type ICMP	Recommandation	Pourquoi
Echo Reply (0)	Autoriser en sortie	Réponse à vos pings
Destination Unreachable (3)	Autoriser (surtout code 4)	Diagnostic + PMTUD
Echo Request (8)	Limiter ou bloquer en entrée	Évite les scans
Time Exceeded (11)	Autoriser	Nécessaire pour traceroute

Glissez pour voir

Ne jamais bloquer Fragmentation Needed

Beaucoup d’équipes bloquent ICMP “par réflexe”. C’est dangereux :

• Type 3 Code 4 (Fragmentation Needed) est critique pour PMTUD
• En IPv6, bloquer ICMPv6 Packet Too Big casse complètement les communications
• Symptômes : TLS qui freeze après le handshake, gros uploads qui timeout

Les types ICMP sont normalisés par l’IANA — consultez-les avant de filtrer.

Cas pratique : VM cloud inaccessible

1. Tester ping

   ping <ip-vm>
   # Timeout...

2. Ne pas conclure trop vite

   Ping peut être bloqué par le Security Group.

3. Tester le port applicatif

   nc -zv <ip-vm> 22
   # Connection to <ip-vm> 22 port [tcp/ssh] succeeded!

   La VM est bien accessible, c’est juste ICMP qui est bloqué.

Environnements modernes : Docker et Kubernetes (facultatif)

Section intermédiaire/avancée

Cette section s’adresse aux utilisateurs de conteneurs. Si vous débutez, vous pouvez la sauter et y revenir plus tard.

Conteneur Docker qui ne ping pas

Dans Docker, les conteneurs peuvent ne pas répondre au ping selon la configuration :

# Depuis l'hôte
ping 172.17.0.2
# Timeout

# Mais le service HTTP fonctionne
curl http://172.17.0.2:8080
# OK

Causes fréquentes :

• Capabilities manquantes : le conteneur n’a pas CAP_NET_RAW (nécessaire pour ping)
• Règles iptables : Docker peut filtrer ICMP selon le network mode
• Politique réseau : des règles bloquent explicitement ICMP

Kubernetes : ping entre pods

# Depuis un pod
kubectl exec -it mypod -- ping autre-service
# Timeout ou succès selon le CNI et les NetworkPolicies

Causes fréquentes en K8s :

• NetworkPolicy qui filtre ICMP (ex : Calico, Cilium)
• Capabilities : le pod n’a pas CAP_NET_RAW dans son securityContext
• PSP/PSA restrictives qui retirent les capabilities réseau

Debug K8s ICMP

# Vérifier si le pod a CAP_NET_RAW
kubectl exec mypod -- cat /proc/1/status | grep Cap

Travaux pratiques

TP 1 : Analyser différents résultats de ping

1. Ping localhost (toujours OK)

   ping -c 2 127.0.0.1

   Notez le temps de réponse (très faible).

2. Ping votre passerelle

   ping -c 2 $(ip route | grep default | awk '{print $3}')

3. Ping une IP publique

   ping -c 2 8.8.8.8

   Comparez les temps de réponse.

4. Ping une IP inexistante sur votre réseau

   ping -c 2 192.168.1.254

   Observez le message d’erreur.

TP 2 : Comprendre traceroute

1. Traceroute vers Google

   traceroute -n google.com

   L’option -n évite la résolution DNS (plus rapide).

2. Identifiez

   • Votre passerelle (premier saut)
   • Les routeurs de votre FAI
   • Les * * * (ICMP bloqué)

3. Comparez avec traceroute UDP

   traceroute -U google.com

   Certains pare-feu bloquent ICMP mais pas UDP.

TP 3 : Observer ICMP avec tcpdump

1. Dans un terminal, capturez ICMP

   sudo tcpdump -i any icmp -n

2. Dans un autre terminal, lancez ping

   ping -c 3 8.8.8.8

3. Observez les paquets

   Vous verrez les Echo Request et Echo Reply.

4. Testez une destination inaccessible

   ping -c 1 192.168.99.99

   Observez le message “Destination Unreachable” dans tcpdump.

ICMPv6 : encore plus critique

En IPv6, ICMPv6 (RFC 4443) n’est pas optionnel — il porte des fonctions essentielles :

Fonction	ICMPv6 Type	Rôle
Echo Request/Reply	128/129	Équivalent de ping (différent de 8/0 en IPv4)
Packet Too Big	2	Équivalent de Fragmentation Needed (PMTUD)
Neighbor Solicitation/Advertisement	135/136	Équivalent d’ARP — indispensable
Router Solicitation/Advertisement	133/134	Auto-configuration réseau

Glissez pour voir

Bloquer ICMPv6 = casser IPv6

Contrairement à IPv4 où ARP est séparé, IPv6 utilise Neighbor Discovery via ICMPv6. Bloquer ICMPv6 casse la résolution d’adresses et l’auto-configuration. Ne filtrez que les types que vous comprenez.

À retenir

• ICMP : protocole de diagnostic (pas de port, juste type + code)
• Ping : Echo Request (type 8) → Echo Reply (type 0)
• Traceroute : envoie des probes (UDP par défaut), reçoit ICMP Time Exceeded (type 11)
• Destination Unreachable (type 3) : plusieurs codes selon la cause
• Type 3 Code 4 : ne jamais bloquer — critique pour PMTUD
• Timeout ≠ Unreachable : timeout = pas de réponse, unreachable = réponse explicite
• Ping bloqué ≠ machine down : testez les ports applicatifs avec nc ou curl
• ICMPv6 : encore plus critique qu’ICMPv4 (porte Neighbor Discovery)
• Pare-feu cloud : bloquent souvent ICMP par défaut

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

Module 8 : DHCP Comment votre machine obtient automatiquement son IP

Module 5 : TCP vs UDP Revoir les protocoles de transport

Retour au parcours Vue d'ensemble de la formation réseau

×

📖 Voir la documentation →