Linux / Commande tracepath : chemin réseau et découverte de PMTU

tracepath examine les étapes du chemin vers une destination et recherche la taille maximale des paquets qui peuvent le parcourir sans fragmentation, appelée Path MTU ou PMTU. L’outil d’iputils fonctionne normalement sans droits administrateur, mais dépend des réponses du réseau. Un saut qui ne répond pas ne prouve pas que le trafic est interrompu à cet endroit.

Lancer une trace vers la bonne destination

Un saut, ou hop, correspond à une étape de routage. tracepath envoie des sondes UDP, User Datagram Protocol, et exploite notamment des erreurs ICMP, Internet Control Message Protocol, pour recueillir des informations. Il produit donc du trafic ; choisissez une destination dont vous êtes autorisé à examiner le chemin.

tracepath [OPTIONS] DESTINATION

tracepath example.com
tracepath -n example.com
tracepath -m 15 example.com

Remplacez example.com par la destination pertinente. -n favorise les adresses numériques dans la sortie et évite les ambiguïtés de noms des routeurs ; il ne supprime pas la résolution initiale d’un nom donné en destination. -m 15 limite la progression à quinze sauts, sans promettre que la destination sera atteinte dans cette limite.

Si le nom possède plusieurs adresses, notez celle réellement choisie pour comparer des observations. -4 et -6 permettent de séparer IPv4 et IPv6. Un résultat dans une famille ne décrit pas le chemin de l’autre. Vérifiez la présence de l’outil et ses options avec man tracepath et tracepath -V ; les paquets et versions disponibles dépendent de la distribution.

Lire les sauts et les réponses manquantes

Exemple fictif et abrégé de structure, sans mesure d’un réseau réel :

1:  gateway.example  0.5ms
2:  no reply
Resume: pmtu 1500

Le numéro de ligne indique le niveau de la sonde ; une adresse ou un nom désigne l’équipement qui a répondu. Le délai en millisecondes est un temps aller-retour de sonde, pas le temps de traversée isolé de ce routeur. no reply signifie qu’aucune réponse exploitable n’a été obtenue pour cette étape.

Un équipement peut transmettre normalement des paquets tout en filtrant ou limitant les réponses aux sondes. Des étapes ultérieures peuvent donc répondre après une étape silencieuse. Inversement, une suite de réponses intermédiaires ne garantit pas qu’un service applicatif soit disponible à l’arrivée.

Les mentions [LOCALHOST], reached, pmtu et le résumé apportent des informations distinctes. reached marque l’arrivée reconnue par cette méthode de sondage ; ce n’est pas une validation HTTP ou SSH. Un nombre suivi de ? est estimé. Les indications asymm et back relatives au retour sont également des estimations et ne constituent pas une cartographie certaine du chemin inverse.

Comprendre la PMTU sans modifier la MTU au hasard

MTU signifie Maximum Transmission Unit, ou unité maximale de transmission. Pour un chemin, la PMTU dépend du lien le plus contraignant parmi les étapes empruntées. Elle s’applique à une taille de paquet IP, pas directement à la quantité de données utiles que votre application doit écrire.

Par exemple, si les liens d’un chemin fictif autorisent 1500, 1480 et 1500 octets, sa contrainte minimale est 1480 octets. Ce raisonnement explique pourquoi la MTU de la première interface ne suffit pas : un tunnel ou une étape ultérieure peut imposer une valeur plus faible. Les en-têtes consomment une partie du paquet ; ne confondez pas PMTU et taille utile d’un message applicatif.

La RFC 1191 sur la découverte de PMTU en IPv4 décrit l’utilisation des messages signalant qu’un paquet est trop grand avec fragmentation interdite. Si les informations nécessaires sont filtrées, une détection peut être incomplète. Une valeur pmtu affichée doit donc être interprétée avec le trajet et les réponses obtenues ; 1500 n’est pas une valeur universelle à appliquer.

Un changement de route peut modifier la PMTU. Avant de changer une interface ou un tunnel, relevez la destination et la famille, comparez la configuration des extrémités et recherchez un problème de filtrage des messages de contrôle. Une seule trace ne justifie pas une modification générale du réseau.

Choisir les options et poursuivre le diagnostic

tracepath est simple à utiliser pour observer chemin et PMTU. traceroute propose davantage de méthodes de sondage et de réglages ; des méthodes différentes peuvent rencontrer des politiques de filtrage différentes et ne pas produire la même vue.

1. Notez la destination résolue, la famille IP et le point de départ. Conservez ces conditions lors d’une comparaison.
2. Vérifiez les interfaces et routes avec la commande ip pour le diagnostic réseau si la trace ne peut pas partir ou ne rejoint pas la destination.
3. Comparez les réponses manquantes, la progression et les changements de pmtu, sans attribuer automatiquement la panne au premier saut silencieux.
4. Contrôlez séparément la réponse du service attendu. Le test ICMP avec ping donne un autre indice, mais ne valide pas non plus le protocole applicatif.

Consultez le manuel tracepath d’iputils pour les marqueurs de sortie et les codes d’erreur. Un résultat !A signale une interdiction administrative rapportée ; un simple silence ne donne pas cette même certitude sur la cause.