ICMP et outils de diagnostic — Introduction à TCP/IP

Table des matières

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

Filtrer ICMP en bloc casse la découverte du PMTU. Les paquets trop grands sont détruits en chemin sans que l'émetteur en soit averti : la connexion s'établit, les petits échanges passent, puis tout se fige au premier transfert volumineux. Ce symptôme — « le site s'ouvre mais le téléchargement gèle » — est la signature du trou noir PMTU.

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.

Traceroute détourne l'expiration du TTL pour cartographier le chemin réseau.

ICMP est le canal de contrôle d'IP. Ping et traceroute sont des clients ICMP, pas des tests applicatifs.

Filtrer « tout ICMP » casse souvent le PMTUD et rend les gros transferts mystérieusement bloqués.

Autorisez au minimum les messages nécessaires au diagnostic et au PMTUD, surtout en IPv6.

ICMP comme signal, pas comme service utilisateur

Echo request/reply (ping) testent joignabilité. Destination unreachable, time exceeded (traceroute) aident au diag. Bloquer tout ICMP « pour sécurité » casse PMTU et certains diagnostics ; filtrer finement est plus sage.

Ping interprété correctement

Ping OK prouve un chemin pour ICMP, pas que le TCP/443 marche. Ping KO ne prouve pas que tout est mort : ICMP peut être filtré. Complétez par test de port (nc, curl, Test-NetConnection).

Traceroute et ses limites

Traceroute s’appuie sur TTL et messages time exceeded. Les * * * indiquent souvent un filtre, pas un trou noir absolu. Les chemins asymétriques trompent. Utilisez-le pour des hypothèses, pas comme vérité judiciaire.

Un bon diag combine ICMP, test de port, DNS et horodatage d’incident.

Boîte à outils minimale

ping, traceroute/mtr, ip route, ss, dig, curl -v, captures ponctuelles. Maîtriser ces outils couvre 80 % des incidents réseau applicatifs courants.

Notez toujours l’heure UTC, la source, la cible, et la commande exacte dans le ticket.

mtr et la lecture de perte le long du chemin

mtr combine ping et traceroute en continu. Une perte sur un hop intermédiaire avec récupération ensuite peut être un rate-limit ICMP, pas une vraie perte de trafic utile. Interprétez avec prudence. Une perte croissante vers la destination est plus parlante.

Couplez avec un test de débit ou de transaction applicative. L’outil réseau sert l’hypothèse métier, pas l’inverse.

Chronométrez aussi les changements : après une fenêtre de maintenance, comparez les chemins. Les reroutes BGP se voient parfois ici en premier côté ressenti utilisateur.

Politique ICMP raisonnable

Autorisez les types nécessaires au PMTU et au diag depuis des bastions, rate-limitez le reste, journalisez les anomalies. Une politique « block all ICMP » est un faux sentiment de sécurité qui augmente les tickets MTU. Revoyez-la avec sécu et réseau ensemble.

Gardez des sondes synthétiques (ping + TCP check + HTTP) depuis plusieurs points. Un seul point de mesure ment. Les outils ICMP restent une brique, pas la cathédrale.

Construire une boîte de smoke tests réseau

Script minimal : résoudre DNS, ping GW, ping cible, traceroute, TCP port, HTTP code. Exécutez-le depuis plusieurs points (user, bastion, DC). Comparez. Automatisez en cron de sonde avec alertes. Vous transformez ICMP et outils associés en filet de sécurité opérationnelle, pas en rituels manuels du vendredi soir.

Ajoutez des tests négatifs : port volontairement fermé doit échouer. Cela valide que vos outils de mesure fonctionnent encore.

Corrélation multi-outils

Un incident solide combine : timeline user, status page fournisseur, sondes synthétiques, ping/mtr, test de port, DNS, capture courte ciblée. Personne n’a besoin de tous les outils à chaque fois ; tout le monde a besoin de savoir lequel ajouter quand l’hypothèse évolue.

Créez un arbre de décision une page, plastifié mentalement. C’est le livrable personnel de ce chapitre.

Limites éthiques et légales du probing

Ne scannez et ne traceroutez pas hors de votre périmètre autorisé. Les outils de diag sont puissants ; leur usage est cadré. En entreprise, centralisez les sondes, évitez que chaque laptop devienne un scanner sauvage. Cette hygiène protège autant juridiquement que techniquement.

Gardez une autorisation écrite pour les tests externes (bug bounty, pentest). ICMP et traceroute font partie du récit.

Approfondissement terrain — icmp-outils

Dans le chapitre icmp-outils, ancrez chaque notion par un exemple vécu ou un lab de cinq minutes. Écrivez le symptôme, l’hypothèse, la commande, le résultat, la conclusion : ce journal personnel accélère votre progression plus que la relecture passive. Partagez ensuite une version anonymisée dans le wiki d’équipe pour capitaliser. Revenez sur ce texte après un incident réel : annotez ce qui manquait. La maîtrise réseau se construit par boucles courtes de pratique, pas par accumulation de slides. Fixez-vous un exercice hebdomadaire de trente minutes jusqu’à ce que les commandes deviennent des réflexes. Variez les contextes : LAN, Wi-Fi, VPN, cloud, conteneur — le même concept change de visage. Quand une explication vous semble floue, reformulez-la sans jargon à un collègue non réseau. Si vous ne pouvez pas la reformuler, la notion n’est pas encore opérationnelle. Fermez chaque session d’étude par une question ouverte que vous résoudrez la fois suivante. Gardez une liste de « myths » à déconstruire : port élevé = sécurité, ping OK = service OK, etc. Ces myths coûtent cher en production ; les tuer est un objectif pédagogique explicite. Mesurez votre temps moyen pour classer un ticket réseau simple : il doit baisser au fil des chapitres. Enfin, reliez toujours la théorie à un risque : disponibilité, confidentialité, ou intégrité. Cas 13: documentez une observation concrète liée à icmp outils dans votre environnement de lab ou de staging.

L'essentiel à retenir

ICMP transporte les messages de contrôle et d'erreur d'IP : destination injoignable, TTL expiré, fragmentation nécessaire. Ping s'appuie sur Echo Request et Echo Reply, traceroute exploite l'expiration progressive du TTL pour révéler chaque routeur du chemin. Bloquer ICMP en bloc casse la découverte du PMTU et provoque des connexions qui restent en suspens.

Questions fréquentes

À quoi sert ICMP ?

ICMP transporte les messages de contrôle et d'erreur d'IP : destination injoignable, TTL expiré, fragmentation nécessaire, etc. Ping et traceroute s'appuient dessus.

Ping prouve-t-il qu'un service web fonctionne ?

Non. Ping teste surtout la reachability IP/ICMP. Un serveur peut répondre au ping tout en ayant HTTP filtré, et inversement.

Comment traceroute trouve-t-il le chemin ?

Il envoie des sondes avec un TTL croissant ; chaque routeur qui expire le TTL renvoie Time Exceeded, révélant ainsi les sauts successifs.

Pourquoi ne pas bloquer tout ICMP ?

Un filtrage trop agressif casse le PMTU discovery et complique le diagnostic. On filtre avec discernement plutôt que de tout couper.

Qu'est-ce que le PMTU ?

Le Path MTU est la plus petite MTU sur le chemin. Sans messages ICMP « fragmentation needed », les connexions peuvent caler sur de gros paquets.

ICMPv6 remplace-t-il aussi ARP ?

Oui, via Neighbor Discovery (NS/NA) et Router Advertisement. ICMPv6 est donc encore plus critique en IPv6 qu'ICMP en IPv4.

Progression sauvegardée dans votre navigateur.

Quiz de validation

Quiz indisponible (données invalides).

De la formation à l'action Nos experts peuvent auditer, tester ou certifier votre organisation.

Devis gratuit