Si vous avez déjà travaillé dans l'espace réseau ou dans le support d'ailleurs, vous avez probablement de bonnes histoires concernant le dépannage d'une connexion perdue. Inévitablement, un nouveau système est installé et configuré, mais nous ne pouvons pas faire passer le trafic vers ou depuis le système.
Une de ces histoires dont je me souviens ressemble à ceci.
Le cas d'utilisation
J'étais en train de dépanner une baie de stockage back-end qui venait d'être installée par une grande société financière américaine bien connue. Le client tentait de configurer la réplication des données de son site de production (PROD) à Houston vers un site de reprise après sinistre (DR) à San Antonio. Le système de reprise après sinistre était implémenté depuis longtemps et avait la réputation d'être une bonne configuration connue.
Le site de production était tout neuf, et bien sûr, la cause de tous nos problèmes. Le vrai problème était que nous n'étions pas en mesure de faire circuler le trafic entre les deux interfaces de réplication que nous avions configurées. Nous avons pu atteindre l'extérieur de la passerelle sur le site DR, mais nous n'avons pas pu atteindre l'extérieur du site PROD. Le trafic atteignait le périphérique de passerelle et était abandonné.
Une demi-heure après le dépannage, j'ai demandé au client s'il avait un pare-feu sur le site PROD qui pourrait bloquer le trafic sur les ports nécessaires. "Bien sûr que non, il n'y a pas de pare-feu entre ces sites." Cette réponse était choquante étant donné qu'il s'agissait de l'une des plus grandes institutions financières de tout le pays. Mais, comme tous les postes en contact avec les clients, vous devez être respectueux et poli.
Donc, j'ai parcouru tous les chèques auxquels je pouvais penser de mon côté. Pare-feu de stockage interne désactivé :vérifiez. Ports ouverts de DR à PROD :vérifier. Ports ouverts de PROD à DR ? Non.
Il s'avère qu'après quatre heures de dépannage et de reconfiguration des interfaces, le client a dit :"Laissez-moi appeler notre pare-feu."
Tu es quoi mec ?
C'est un poste étrange à embaucher pour avoir considéré que vous n'avez pas de pare-feu entre ces sites. Mais ce n'était pas bizarre, car bien sûr, ils avaient un pare-feu. Problème résolu. Maintenant que le cauchemar était terminé, les outils que j'ai utilisés pour déterminer où le problème s'est produit étaient le bon vieux Telnet (que nous pourrons aborder dans un article ultérieur) et bien sûr, traceroute .
La commande
Maintenant que vous pouvez voir un cas d'utilisation clair pour traceroute , parlons de la commande elle-même et des informations que vous pouvez en tirer. Le but de cet article, après tout, est que vous repartiez avec un peu plus de connaissances sur l'utilitaire que traceroute offres.
La syntaxe est plutôt simple. La commande traceroute <x> (x ici étant une adresse IP ou un nom d'hôte) est la version la plus basique et elle commencera à envoyer des paquets à la cible désignée. Ce résultat vous permettra de tracer le chemin des paquets envoyés depuis votre machine vers chacun des systèmes entre vous et la destination souhaitée.
Par exemple, si je voulais tracer le chemin de mon ordinateur vers google.com , je saisirais quelque chose comme ceci :
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 119.355 ms 119.315 ms 119.508 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 120.321 ms 119.836 ms 120.009 ms
5 66.sub-69-83-106.myvzw.com (69.83.106.66) 119.042 ms 119.489 ms 119.156 ms
6 2.sub-69-83-107.myvzw.com (69.83.107.2) 120.039 ms 125.954 ms 101.450 ms
7 112.sub-69-83-96.myvzw.com (69.83.96.112) 110.757 ms 108.485 ms 122.108 ms
8 112.sub-69-83-96.myvzw.com (69.83.96.112) 115.028 ms 121.073 ms 125.537 ms
9 116.sub-69-83-96.myvzw.com (69.83.96.116) 121.793 ms 124.769 ms 124.434 ms
10 Bundle-Ether10.GW6.DFW13.ALTER.NET (140.222.237.123) 128.082 ms 128.400 ms 126.509 ms
11 google-gw.customer.alter.net (204.148.43.118) 106.276 ms 107.885 ms 105.718 ms
12 108.170.252.129 (108.170.252.129) 99.725 ms 101.797 ms 108.170.252.161 (108.170.252.161) 101.671 ms
13 108.170.230.109 (108.170.230.109) 101.207 ms 100.515 ms 99.730 ms
14 dfw06s48-in-f100.1e100.net (216.58.194.100) 99.059 ms 94.502 ms 94.015 ms
[root@rhel8dev ~]# La panne
Décomposons ces résultats en petites bouchées. Cette commande peut produire beaucoup d'informations, et comme le dit le proverbe :"La meilleure façon de manger un éléphant est une bouchée à la fois :"
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms Nous ne regardons ici que le premier saut. Cependant, nous pouvons utiliser ce saut pour disséquer les informations affichées. Tout d'abord, nous voyons ce qui est réellement envoyé, et où :
traceroute to www.google.com(IP), 30 hops max, 60 byte packets
À partir de cette sortie, nous déduisons que nous envoyons du trafic vers la cible souhaitée (www.google.com ). Traceroute, par défaut, mesure 30 sauts de paquets de 60 octets.
Ensuite, nous voyons le premier saut se produire. Ici, nous atteignons la passerelle externe :
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
Vous pouvez dire ici où le premier saut a réellement atterri, puis il y a trois valeurs numériques. Ceux-ci sont connus sous le nom de temps d'aller-retour (RTT), qui fait référence au temps nécessaire à un paquet donné pour atteindre sa destination et renvoyer un message ICMP à la source. Par défaut, traceroute achemine trois paquets de données pour tester chaque saut. Vous pouvez trouver plus d'informations sur ce processus en ligne, cependant, en bref, chaque paquet renvoie un message d'erreur ICMP vers la source lorsqu'il atteint un périphérique sur le réseau. Cette action permet traceroute pour déterminer le RTT de ce paquet et n'indique pas nécessairement une erreur.
Examinons maintenant les sauts 2 à 4 :
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 109.206 ms 109.400 ms 109.423 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 124.793 ms 123.585 ms 124.585 ms Nous pouvons voir quelque chose de nouveau ici. Le saut 2 semble normal :un appareil est touché par des temps RTT dans la plage de 100 millisecondes. Ensuite, ça devient intéressant. On ne voit que des étoiles (*).
Que signifient ces étoiles (astérisques) ? Les paquets ont-ils été lâchés ? Sont-ils expirés ?
Laisse-moi expliquer. Il y a deux possibilités en ce qui concerne ces étoiles. Tout d'abord, ICMP/UDP n'est peut-être pas configuré. Si le traceroute La commande se termine avec succès et vous voyez ces étoiles, très probablement le périphérique qui a été touché n'a pas été configuré pour répondre au trafic ICMP/UDP. Ce résultat ne signifie pas que le trafic n'a pas été transmis. La deuxième possibilité est que les paquets ont été supprimés en raison d'un problème sur le réseau. Ces résultats sont généralement des délais d'attente de paquets ou le trafic a été bloqué par un pare-feu.
Comme vous pouvez le voir dans l'exemple ci-dessus, même après avoir vu des étoiles au saut 2, les paquets continuent et sont renvoyés au saut 4. Ce comportement conduit à un traceroute réussi. car nous pouvons voir que Google a été contacté.
La vente à emporter
Traceroute peut être un outil inestimable pour résoudre les problèmes de réseau. Cela aide vraiment à visualiser où le problème se produit réellement. Bien sûr, il y a d'autres opérations en cours dans les coulisses de traceroute qui n'étaient pas couverts ici.
Je vous suggère fortement, si vous souhaitez un examen encore plus approfondi de cet outil, de faire des recherches en ligne. Il y a beaucoup d'informations sur Time-to-Live (TTL) et RTT qui, dans l'intérêt du temps, n'ont pas été incluses dans cet article. Mon objectif est que vous ayez maintenant une meilleure compréhension de quand et pourquoi vous devriez utiliser le traceroute outil, et comment interpréter les données qu'il offre. Pour plus d'informations sur le dépannage et les concepts de mise en réseau, consultez nos articles connexes ici.