Dans cette section, je décris brièvement certains des outils usuels de diagnostic que l'on trouve pour votre réseau Linux, et comment vous pouvez les utiliser pour identifier la cause de vos problèmes de réseaux, ou pour vous apprendre un peu plus comment fonctionne un réseau tcp/ip. J'ai passé sous silence quelques détails concernant la manère dont travaille les outils car ce document n'est pas l'endroit adéquat pour les décrire, mais j'espère présenter suffisamment d'informations pour que vous compreniez comment utiliser les outils et que vous compreniez mieux les pages man correspondantes, ou tout autre documentation.
L'outil ping est compris dans la distribution NetKit-B comme indiqué plus haut dans la section `Les applications réseau'. ping, comme son nom le laisse supposer, vous permet de transmettre un datagramme à un autre hôte qui vous le renverra si il est en activité et qu'il fonctionne correctement, et le réseau intermédiaire aussi. Dans sa forme la plus simple, vous faites:
# ping gw
PING gw.vk2ktj.ampr.org (44.136.8.97): 56 data bytes
64 bytes from 44.136.8.97: icmp_seq=0 ttl=254 time=35.9 ms
64 bytes from 44.136.8.97: icmp_seq=1 ttl=254 time=22.1 ms
64 bytes from 44.136.8.97: icmp_seq=2 ttl=254 time=26.0 ms
^C
--- gw.vk2ktj.ampr.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 22.1/28.0/35.9 ms
#
Les deux dernières lignes vous donnent combien de paquets ont été envoyés, combien de bonnes réponses ont été reçues et le pourcentage de paquets qui ont été perdus. Le pourcentage de pertes est une mesure de la qualité de la connexion. Un pourcentage élevé de pertes indique des problèmes tels qu'un taux d'erreurs élevé quelque part sur la liaison entre les deux hôtes, une capacité épuisée sur un routeur ou une liaison ou un fort taux de collisions sur un réseau ethernet. Vous pouvez utiliser ping pour identifier où le problème se situe en effectuant des sessions ping sur chacun des points de la route du réseau.
L'outil traceroute se trouve dans la distribution NetKit-A détaillée plus haut. traceroute a pour but initial de tester et de montrer le chemin que votre connexion réseau doit prendre pour aller vers un hôte. traceroute utilise aussi le protocole icmp, mais il utilise un truc intelligent pour obtenir chaque point le long du chemin et renvoie une réponse au fur et à mesure qu'il progresse. Ce truc consiste à manipuler manuellement le champ time to live des paquets transmis. Le champ time to live est un mécanisme qui s'assure que les paquets solitaires ne soient emprisonnés dans une boucle de routage. Chaque fois qu'un paquet passe par un routeur, il décrémente le champ time to live d'une unité. Si time to live atteint zéro alors ce routeur ou hôte envoie un message icmp time to live expired à l'émetteur du paquet pour lui signifier que ce paquet n'est plus valide. traceroute utilise ce mécanisme en envoyant une série de paquets udp ayant leur time to live commençant à 1 et qui s'incrémente à chaque étape. En enregistrant les adresses qui répondent icmp time to live expired lorsque les paquets expirent, il peut déterminer le trajet suivi pour arriver à la destination. Un exemple d'utilisation ressemble à ceci:
# traceroute minnie.vk1xwt.ampr.org
traceroute to minnie.vk1xwt (44.136.7.129), 30 hops max, 40 byte packets
1 gw (44.136.8.97) 51.618 ms 30.431 ms 34.396 ms
2 gw.uts (44.136.8.68) 2017.322 ms 2060.121 ms 1997.793 ms
3 minnie.vk1xwt (44.136.7.129) 2205.335 ms 2319.728 ms 2279.643 ms
#
La première colonne nous dit combien de bonds plus loin (quelle était la valeur de ttl), la seconde colonne quel est le nom de l'hôte et son adresse qui a répondu , si il peut être résolu ou seulement son adresse si ce n'est pas le cas. Les troisièmes, quatrièmes et cinquièmes colonnes sont les temps d'aller et retour pour trois paquets consécutifs vers ce point. Ceci nous dit que le premier bond le long de la route est via gw.vk2ktj et que les trois chiffres suivants sont les allers et retours vers ce routeur. Le bond suivant est via gw.uts.ampr.org et minnie.vk1xwt.apr.org est un bond plus loin. Vous pouvez en déduire des informations sur le chemin réseau en regardant les différences de temps entre chaque étape sur la route. Vous pouvez voir que les allers et retours pour gw sont relativement rapides, c'est un hôte connecté par ethernet. gw.uts est substantiellement plus lent à obtenir que gw, c'est par le biais d'une liason radio de faible vitesse, puis vous avez le temps ethernet et le temps radio ajoutés ensemble. minnie.vk1xwt est un peu plus lent que gw.uts, étant reliés par un réseau à grande vitesse.
Si vous effectuer traceroute et que vous voyez la chaîne !N apparaitre aprè le chiffre donnant le temps, cela indique que votre programme traceroute a reçu une réponse
network unreachable (réseau inatteignable). Ce message vous indique que l'hôte ou le routeur qui vous a envoyé cd message ne connait par le chemin vers l'adresse de destination.
Cela indique habituellement qu'il y a un lien réseau cassé quelque part.
La dernière adresse que vous avez obtenue est celle juste avant la liaison en défaut.
De manière similaire si vous voyez la chaîne !H cela indique qu'un message
host unreachable (hôte non atteignable) a été reçu. Cela peut vouloir dire que vous allez jusqu'à la carte ethernet où l'hôte éloigné est connecté, mais l'hôte lui-même ne répond pas ou est en défaut.
Adam Caldwell <acaldwel@103mort2.cs.ohiou.edu> a réalisé le portage de
tcpdump sous linux. tcpdump vous permet de tracer les
activités réseau en interceptant les paquets entrant et sortant. C'est très
utile pour diagnostiquer des problèmes réseau ardus.
Vous pouvez trouver les sources et les binaires à : 103mor2.cs.ohiou.edu
tcpdump décode chacun des paquets qu'il intercepte et les affiche sous un format texte légèrement crypté. Vous devriez utiliser tcpdump si vous essayez de diagnostiquer un problème comme des erreurs de protocole, ou des déconnexions bizarres, ceci car il vous permet de voir en réel ce qui arrive sur le réseau. Pour bien utiliser tcpdump vous devez avoir quelques connaissances sur les protocoles et comment ils fonctionnent, mais il est aussi utile pour quelques services simples comme vérifier que les paquets quittent bien votre machine par le bon port si vous essayez de diagnostiquer des problèmes de routage et pour voir si vous recevez des paquets en provenance de destinations éloignées.
Un exemple de ce que répond tcpdump ressemble à ceci:
# tcpdump -i eth0
tcpdump: listening on eth0
13:51:36.168219 arp who-has gw.vk2ktj.ampr.org tell albert.vk2ktj.ampr.org
13:51:36.193830 arp reply gw.vk2ktj.ampr.org is-at 2:60:8c:9c:ec:d4
13:51:37.373561 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:37.388036 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:38.383578 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:38.400592 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:49.303196 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: S 700506986:700506986(0) win 512 <mss 1436>
13:51:49.363933 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 1103372289 win 14261
13:51:49.367328 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: S 1103372288:1103372288(0) ack 700506987 win 2048 <mss 432>
13:51:49.391800 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 134 win 14198
13:51:49.394524 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: P 1:134(133) ack 1 win 2048
13:51:49.524930 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: P 1:28(27) ack 134 win 14335
..
#
Le nombre ou nom à la fin de chaque nom d'hôte indique quel numéro de socket est utilisé. tcpdump regarde dans votre fichier /etc/services pour effectuer la traduction.
tcpdump éclate chacun des champs et vous pouvez voir les valeurs des paramètres window et mss de quelques uns des paquets.
La page man documente toutes les options disponibles.
Note pour les utilisateurs de PPP: La version de tcpdump qui est actuellement disponible ne supporte pas la suite PPP des protocoles.
Al Longyear a écrit des patches pour corriger ceci, mais ils ne sont pas encore inclus dans une distribution tcpdump. Les fichiers patch sont sités dans le même répertoire que l'ensemble tcpdump sur sunsite.unc.edu.
ICMP (Internet Control Message Protocol) donne des informations utiles sur la santé de votre réseau IP. Souvent les messages ICMP sont reçus et agissent en silence, si bien que vous ne percevez pas leur présence. icmpinfo est un outil qui vous permettra de voir les messages ICMP beaucoup mieux que le fait tcpdump.
Laurent Demailly <dl@hplyot.obspm.fr> prit les sources bsd de ping et les modifia profondément.
La version 1.10 est disponible:
hplyot.obspm.fr
/net/icmpinfo-1.10.tar.gz
La compilation est aussi simple que çà:
# cd /usr/src
# cd icmpinfo-1.10
# gzip -dc icmpinfo-1.10.tar.gz | tar xvf -
# make
Vous devez être root pour activer icmpinfo. icmpinfo peut soit envoyer les signaux décodés sur le terminal qui l'a appelé soit les envoyer dans le fichier syslog.
Pour vérifier son fonctionnement, démarrez icmpinfo puis faites traceroute vers un hôte éloigné. Vous verrez les messages icmp que traceroute utilise sur la console.