Guide rapide de débogage TCP/IP

Linux Gazette n°96 - Novembre 2003

David Dorgan


Table des matières
1. Introduction
2. Eléments de diagnostic de certains événements

Voici un petit guide que j'ai écrit sur le débogage des réseaux TCP/IP. Il part de l'hypothèse que vous utilisez Linux ou tout autre système d'exploitation de type Unix.


1. Introduction

Donc, à 17h00, un vendredi, un utilisateur indique qu'il ne peut pas se connecter à $un-site-web-quelconque. Que faites vous ? Il y a quelques pistes, même si souvent il vous faudra utiliser une approche différente pour les sites internes et pour les sites externes.

Certaines choses ne changeront pas, par exemple, si la couche physique ne fonctionne pas, tout ce qui se trouve au-dessus ne fonctionnera pas non plus. Un certain nombre d'outils comme telnet, ping, traceroute, tracepath, etc... peuvent être utiles pour voir où se situe le problème et, si vous pouvez, voir quelles couches fonctionnent correctement. Par exemple, si vous pouvez faire un ping et un traceroute sur un hôte, et que vous pouvez accéder au port 25, mais pas au port 80, il y a alors toutes les chances pour qu'il s'agisse d'une panne du serveur web distant. Lorsque vous ne pouvez pas franchir votre passerelle locale, mais que vous pouvez faire un ping sur cette passerelle, il est possible qu'elle ne transmette rien, qu'il s'agisse d'un problème de configuration de pare-feu, etc...

Essayez de faire un telnet sur le port 80 de le-site.com pour vérifier si vous pouvez vous connecter. Si la connexion est refusée et si vous n'avez pas de pare-feu ou de proxy bloquant les communications vers l'extérieur, il se peut qu'il y ait une interruption d'un service quelconque. S'il se contente d'attendre un moment et finit par afficher « connexion impossible » (« cannot connect »), alors continuez.

Essayez de faire un ping sur le site distant. Bien que ce soit très utile, certains sites bloquent l'ICMP (Internet Control Message Protocol, protocole de contrôle de message Internet) : ils doivent avoir l'impression que, lors de la création de TCP/IP, la plus grande partie du travail a été effectuée durant les six premiers jours et que, comme ils n'avaient rien à faire le dimanche, ils ont inventé ICMP pour se distraire. Dans ce cas, vous pouvez essayer traceroute : encore une fois, il peut arriver que celui-ci soit bloqué, mais il vous donnera généralement une idée de l'endroit où se situe le problème. À ce stade, regardez où il s'arrête : vous devriez voir votre passerelle locale et peut-être certains routeurs internes des passerelles. Ensuite, vous devriez la voir passer à travers les réseaux des FAIs. Lorsque vous ne voyez votre FAI nulle part et que traceroute s'arrête sur les premiers sauts, il peut y avoir un problème de liaison avec votre FAI. S'il affiche votre FAI et une interruption juste après, peut-être que le FAI a perdu la liaison vers un de ses canaux montants et que les anciens chemins sont encore valides : en conséquence, les paquets sont arrêtés à cet endroit. Pour finir, vous pouvez voir traceroute aller jusqu'au bout ou s'arrêter sur une-entreprise-gw.client.fai.net, auquel cas l'autre extrémité est susceptible de bloquer les ICMPs entrants.

S'ils ne peuvent se connecter à rien, demandez aux utilisateurs d'essayer de se connecter via une adresse IP (Internet Protocol, protocole Internet). Si cela fonctionne, faites-leur vérifier leur configuration DNS (Domain Name Server, serveur de noms de domaine).


2. Eléments de diagnostic de certains événements

David a été un auteur très productif et envisage de contribuer davantage à cette tâche à l'avenir.

Copyright © 2003, David Dorgan

Copying license http://www.linuxgazette.com/copying.html

Paru dans le n°96 de la Linux Gazette de novembre 2003.

Traduction française par Gabriel Giovannetti .

Relecture de la traduction française par Isabelle Hurbain .