Effectuer un diagnostic MTR/Traceroute
Guide complet pour utiliser MTR et Traceroute afin de diagnostiquer les problèmes de connectivité réseau et identifier les points de latence sur votre VPS VeryCloud.
🔍 Effectuer un diagnostic MTR/Traceroute
Ce guide vous apprendra à utiliser MTR (My Traceroute) et Traceroute pour diagnostiquer les problèmes de connectivité réseau, identifier les points de latence et analyser la qualité de votre connexion réseau.
📋 Prérequis
- Un serveur VPS VeryyCloud avec accès root ou sudo
- Une connexion SSH active
- Ubuntu/Debian (les commandes sont adaptées pour ces distributions)
🔧 Installation
Installation de Traceroute (outil de base)
# Sur Ubuntu/Debian
sudo apt update
sudo apt install traceroute -y
Installation de MTR (outil avancé)
MTR combine les fonctionnalités de ping et traceroute en un seul outil puissant.
# Sur Ubuntu/Debian
sudo apt update
sudo apt install mtr-tiny -y
# Pour la version complète avec interface graphique (optionnel)
sudo apt install mtr -y
Vérification de l'installation
# Vérifier que traceroute est installé
traceroute --version
# Vérifier que MTR est installé
mtr --version
🛠️ Utilisation de Traceroute
Commande de base
# Traceroute vers une destination
traceroute google.com
# Traceroute vers une IP
traceroute 8.8.8.8
# Limiter le nombre de sauts (par défaut 30)
traceroute -m 20 google.com
# Spécifier le timeout en secondes
traceroute -w 5 google.com
Options utiles
# Utiliser UDP (par défaut)
traceroute -U google.com
# Utiliser TCP (plus fiable)
traceroute -T google.com
# Utiliser ICMP (comme ping)
traceroute -I google.com
# Ne pas résoudre les noms DNS (plus rapide)
traceroute -n google.com
Exemple de sortie
traceroute to google.com (142.250.185.14), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.123 ms 0.089 ms 0.067 ms
2 192.168.1.1 (192.168.1.1) 5.234 ms 5.189 ms 5.145 ms
3 * * *
4 8.8.8.8 (8.8.8.8) 12.456 ms 12.389 ms 12.334 ms
...
🚀 Utilisation de MTR (recommandé)
MTR est plus puissant car il envoie des paquets en continu et calcule des statistiques en temps réel.
Commande de base
# MTR en mode interactif (recommandé)
mtr google.com
# MTR avec rapport (non-interactif)
mtr --report google.com
# MTR avec 10 paquets de test
mtr --report --report-cycles 10 google.com
# MTR vers une IP
mtr --report 8.8.8.8
Options avancées
# Spécifier le nombre de paquets à envoyer
mtr --report --report-cycles 50 google.com
# Utiliser TCP au lieu d'ICMP
mtr --tcp --port 80 google.com
# Utiliser UDP
mtr --udp --port 53 8.8.8.8
# Ne pas résoudre les noms DNS
mtr --no-dns google.com
# Intervalle entre les paquets (en secondes)
mtr --interval 2 google.com
# Taille des paquets (en octets)
mtr --psize 64 google.com
Mode interactif MTR
Quand vous lancez mtr sans l'option --report, vous entrez en mode interactif :
| Touche | Action |
|---|---|
| d | Affiche/masque les statistiques détaillées |
| n | Active/désactive le mode DNS (résolution des noms) |
| r | Réinitialise les statistiques |
| s | Change la taille des paquets |
| j | Change l'intervalle entre les paquets |
| q | Quitte MTR |
📊 Interprétation des résultats
Latence normale
| Latence | Qualité | Description |
|---|---|---|
| < 50 ms | Excellent | Réseau local ou très proche |
| 50-100 ms | Bon | Connexion régionale |
| 100-200 ms | Acceptable | Connexion intercontinentale |
| > 200 ms | Élevé | Peut causer des problèmes |
Paquets perdus
| Perte | État | Action |
|---|---|---|
| 0% | Parfait | Aucune action nécessaire |
| < 1% | Normal | Comportement standard Internet |
| 1-5% | Acceptable | Surveillance recommandée |
| > 5% | Problématique | Investigation nécessaire |
Signification des astérisques (*)
Dans traceroute, un * signifie :
- Un seul * à la place d'un temps : Le routeur n'a pas répondu à ce paquet spécifique
- Trois * consécutifs : Le routeur n'a pas répondu du tout (timeout ou filtre de pare-feu)
🎯 Cas d'utilisation
Diagnostic de latence élevée
# Tester vers Google DNS
mtr --report --report-cycles 30 8.8.8.8
# Tester vers Cloudflare DNS
mtr --report --report-cycles 30 1.1.1.1
# Identifier le saut problématique
mtr --report --report-cycles 50 votre-domaine.com
Diagnostic de perte de paquets
# Test avec TCP pour contourner les filtres ICMP
mtr --tcp --port 443 --report --report-cycles 50 google.com
# Test vers un serveur spécifique
mtr --report --report-cycles 100 votre-serveur.com
Test depuis votre VPS vers votre localisation
# Tester vers votre adresse IP publique
# Récupérez votre IP publique d'abord
curl ifconfig.me
# Puis testez depuis votre VPS
mtr --report --report-cycles 30 VOTRE_IP_PUBLIQUE
🔍 Diagnostic de problèmes courants
Problème : Latence élevée sur un saut spécifique
Si vous voyez une latence élevée sur un saut intermédiaire :
# Tester avec différents protocoles
mtr --tcp --port 443 --report google.com
mtr --udp --port 53 --report 8.8.8.8
mtr --report google.com
Important : Une latence élevée sur un saut intermédiaire peut être normale si ce routeur ne répond pas rapidement aux requêtes de diagnostic, mais la latence finale reste bonne.
Problème : Perte de paquets importante
Si vous voyez une perte de paquets élevée :
# Tester avec plus de paquets pour confirmer
mtr --report --report-cycles 100 destination.com
# Tester avec TCP si ICMP est filtré
mtr --tcp --port 80 --report --report-cycles 50 destination.com
Attention : Si la perte de paquets apparaît sur tous les sauts, le problème est probablement sur votre VPS ou votre connexion locale. Si elle apparaît uniquement sur un saut spécifique, le problème est sur le réseau entre votre VPS et la destination.
Problème : Timeouts répétés
# Augmenter le timeout
mtr --timeout 10 --report destination.com
# Tester avec différents protocoles
mtr --tcp --port 443 --timeout 10 --report destination.com
📝 Commandes utiles
Script de diagnostic complet
Créez un script pour tester plusieurs destinations :
#!/bin/bash
echo "=== Test MTR vers Google DNS ==="
mtr --report --report-cycles 30 8.8.8.8
echo -e "\n=== Test MTR vers Cloudflare DNS ==="
mtr --report --report-cycles 30 1.1.1.1
echo -e "\n=== Test MTR vers votre domaine ==="
mtr --report --report-cycles 30 votre-domaine.com
Sauvegarder les résultats
# Sauvegarder le rapport dans un fichier
mtr --report --report-cycles 30 google.com > mtr-report-$(date +%Y%m%d).txt
# Avec format CSV
mtr --report --report-cycles 30 --csv google.com > mtr-report.csv
✅ Bonnes pratiques
- Utilisez MTR plutôt que traceroute : MTR fournit des statistiques plus complètes
- Testez plusieurs destinations : Comparez les résultats vers différents serveurs
- Faites plusieurs tests : Les réseaux peuvent varier, faites plusieurs tests à différents moments
- Utilisez TCP si ICMP est filtré : Certains routeurs filtrent ICMP mais pas TCP
- Interprétez correctement les résultats : Une latence élevée sur un saut intermédiaire n'est pas toujours un problème si la latence finale est bonne
🆘 Dépannage
MTR ne s'affiche pas correctement
# Si MTR ne fonctionne pas en mode interactif, utilisez le mode rapport
mtr --report destination.com
# Vérifier la version de MTR
mtr --version
Erreur "mtr: command not found"
# Réinstaller MTR
sudo apt update
sudo apt install mtr-tiny -y
# Ou installer la version complète
sudo apt install mtr -y
Les résultats montrent tous des astérisques
Si tous les sauts montrent des *, cela peut signifier :
# Votre pare-feu bloque ICMP
# Testez avec TCP à la place
mtr --tcp --port 443 --report destination.com
# Vérifiez les règles de pare-feu
sudo ufw status
sudo iptables -L
❓ Questions fréquentes
Q : Quelle est la différence entre Traceroute et MTR ? R : Traceroute envoie quelques paquets et affiche les résultats. MTR envoie des paquets continuellement et calcule des statistiques en temps réel, ce qui est plus utile pour le diagnostic.
Q : Pourquoi certains sauts montrent des astérisques ? R : Cela signifie que le routeur n'a pas répondu. Cela peut être dû à un filtre de pare-feu, une configuration de routeur, ou simplement que le routeur ne répond pas aux requêtes de diagnostic.
Q : Dois-je m'inquiéter d'une latence élevée sur un saut intermédiaire ? R : Pas nécessairement. Si la latence finale vers la destination est bonne, une latence élevée sur un saut intermédiaire peut être normale. C'est la latence finale qui compte vraiment.
Q : Comment interpréter la perte de paquets dans MTR ? R : Une perte de paquets < 1% est normale. Entre 1-5%, c'est acceptable mais peut causer des problèmes. Au-delà de 5%, c'est problématique et nécessite une investigation.