Copyright © 2003 David Dorgan
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).
Un service en panne avec un réseau qui fonctionne bien : vous pouvez faire un ping et un traceroute correctement et vous connecter sur d'autres ports ouverts. Par exemple, lorsque la machine est consacrée à la messagerie et à l'accès distant et que vous pouvez accéder au port 22 (ssh), mais pas au port 25 (smtp), le problème se limite peut-être à l'agent de transfert de message (MTA, Mail Transfer Agent).
Un pare-feu bloquant un port : ce dernier ne fonctionne pas très bien quand les routeurs ou les pare-feu ont un « deny all » par défaut, mais la plupart des utilisateurs ne font pas cela. Supposons que vous ne pouvez pas accéder au port 25 sur cette machine. Lorsque vous essayez un telnet, vous obtenez juste un « time out ». Comme vous savez qu'il s'agit d'un serveur de messagerie, essayez un telnet sur quelques ports, simplement des numéros de ports élevés aléatoires, comme 8274 ou 9274 et vérifiez si la connexion est refusée. Dans ce cas, il y de grandes chances que le pare-feu ne bloque que le port 25 à cause de votre adresse IP, puisque la machine a répondu que vous ne pouvez pas accéder à ces ports.
La liaison avec votre FAI est interrompue : essayez de faire un traceroute sur n'importe quelle cible. Vous constaterez que le dernier saut qui ne génère pas de time out est interne à votre entreprise et vous ne verrez jamais rien avec liaison-quelconque.fai.net.
Liaison interrompue chez le destinataire : vous savez que votre destinataire ne bloque par les paquets traceroute et lorsque vous utilisez cette commande, elle passe par votre FAI, un porteur, le FAI de votre destinataire, et s'arrête à ce qui est normalement la liaison de son FAI.
Problème de routage chez votre FAI : ceci se produit souvent avec certains fournisseurs d'accès « ahem ». J'ai des comptes sur quelques machines, basées dans des lieux physiquement différents et utilisant des fournisseurs d'accès différents. Si je ne peux pas accéder à la ressource que je souhaite, j'essaie un traceroute vers cette ressource depuis une machine connectée directement à LINX et à d'autres machines connectées directement à certains fournisseurs d'accès américains. Lorsque tout semble fonctionner de là-bas et qu'un traceroute de votre poste donne des time outs ou des temps de latence inhabituels au niveau de londres.fai.net par exemple, leurs liaisons vers Londres peuvent être surexploitées ou avoir des problèmes.
Il faut environ 2 minutes pour se connecter à une machine : lorsque vous vous connectez, saisissez w ou who et vérifiez si la machine indique que vous venez d'un IP ou d'un nom d'hôte. Elle ne devrait pas répondre un nom d'hôte, elle attend simplement trop longtemps dans les DNS et devrait utiliser un serveur DNS interne qui répondra rapidement. Sinon, vous pouvez utiliser la résolution inverse (reverse lookup) des adresses IP.
Quelqu'un se plaint de ne pas pouvoir se connecter à un service : vous essayez une connexion manuelle depuis un hôte extérieur et elle ne fonctionne pas. Sur la machine, essayez de faire un telnet sur le port ou un netstat -an | grep LISTEN et cherchez le numéro de port que le service devrait écouter. S'il est présent, il est peut-être filtré quelque part sur la route, voire sur l'hôte local. Si le port n'est pas écouté, un fstat ou un lsof associé à un grep sur le nom de processus peut afficher une ligne IPv4 ou internet indiquant l'adresse IP et l'hôte sur lequel il écoute.
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 <gabriel POINT giovannetti CHEZ tiscali POINT fr>.
Relecture de la traduction française par Isabelle Hurbain <isabelle POINT hurbain CHEZ free POINT fr>.