|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Le guide du routard internaute Cela fait des heures qu'un serveur Web est inaccessible ? Que votre courrier ne quitte pas votre machine ou inversement n'arrive plus ? Vous n'avez même plus de cheveux à vous arracher et la télé-assistance vous diffuse depuis des heures "un, dos, tres" : pas de panique ! Vous devez sortir de toute urgence votre trousse de premiers secours. Quand tout va mal, vous devez faire deux vérifications (la première et la deuxième :)). Étape n°1 : état de la connexion entre votre Amiga et le serveur ou la machine que vous tentez de joindre Deux commandes vont vous permettre de savoir si vous avez un problème de connexion et si oui, quelle est sa nature.
Le nom de la machine peut être soit son nom usité comme "mail.freenet.fr", soit son adresse IP, 194.250.152.3. Cette commande permet de savoir si la machine que vous tentez de joindre est vivante. Dans l'affirmative, celle-ci répond, et vous aurez des informations sur l'état de la connexion (réponse lente ou normale, perte d'information ou non). Exemple 1
Ici tout va bien, le serveur répond et aucune information test n'a été perdue. Il n'y a donc pas de problème de connexion, il faut passer à l'étape suivante. Exemple 2
Ici c'est une catastrophe, la machine ne répond pas et toutes les informations tests ont été perdues. Aucune conclusion sérieuse ne peut cependant être tirée : en effet, certaines machines sont configurées pour ne pas répondre à un ping, le problème de connexion peut ne pas être sur la machine elle-même mais sur une partie du réseau utilisé pour tenter de la joindre. Il faut alors passer à la commande suivante.
Cette commande permet de savoir par où une information circule pour atteindre la machine. Cependant, Il faut garder à l'esprit que sur Internet, une information ne va pas forcément à chaque coup suivre la même route : le routage est dit "dynamique" c'est-à-dire qu'il n'est jamais défini à l'avance mais au fur et à mesure. On peut cependant l'utiliser pour découvrir à quel niveau se situe un éventuel problème de connexion. Exemple 1
(un Control-C a interrompu la commande...) Maintenant, je peux conclure qu'il existe un réel problème de connexion qui rend impossible l'accès au serveur www.microsoft.com. Les informations tests arrivent jusqu'à la machine 207.68.145.46 (qui n'a pas de nom) et ensuite elles ne peuvent plus être routées : la machine suivante est peut-être indisponible, il y a peut-être un problème de câblage, etc. Exemple 2
Ici tout va bien, la trace est complète et j'apprends que ftp.jussieu.fr a aussi pour nom nephtys.lip6.fr. Dans le cas ou les deux commandes ping et traceroute lèvent le doute sur un problème éventuel de connexion, il faut passer à l'étape n°2. Dans le cas contraire, il ne faut pas hésiter à appliquer les deux commandes sur les machines de son fournisseur d'accès à l'Internet pour vérifier la qualité et l'état de sa connexion avec lui. Étape n°2 : état du service que vous tentez d'utiliser Vous êtes certain de ne pas avoir de problème de connexion avec la machine en question mais peut-être le service (email, ftp, pop, web, etc.) n'est pas disponible. La commande telnet va peut-être vous permettre de faire quelques vérifications. Le peut-être est de rigueur : en effet, il existe des machines appelées proxy qui contrôlent les activités et les commandes lancées sur une machine de son réseau et qui peuvent rejeter la commande telnet que vous lancez.
"NomDuProtocole" étant soit le nom du protocole du service utilisé (http pour le Web, smtp pour envoyer du courrier, pop pour lire du courrier déporté, ftp pour le transfert de fichier, etc.) soit le numéro de port (ou canal) que le service utilise (25 pour l'envoi de courrier, 119 pour les news, 80 pour le Web, etc.). Cas n°1 : le service n'est pas actif
Soit un proxy vous interdit de vous connecter sur cette machine (pour y remédier voir cas n°2), soit le service n'est pas disponible et vous n'avez plus qu'à attendre son rétablissement. Cas n°2 : le service est actif mais vous ne pouvez pas l'utiliser
Dans ce cas, le service des forums Usenet est bien opérationnel mais vous n'avez pas les droits nécessaires pour vous connecter ou dialoguer avec le service. Celui-ci est réservé à certaines personnes dont vous ne faites pas partie. Si cette situation est anormale vous devez contacter par tous les moyens le responsable du site (ou son représentant). Cas n°3 : le service est actif et vous pouvez l'utiliser
Ici tout va bien, le service des forums Usenet est opérationnel et vous avez la permission de vous connecter sur le serveur Usenet. Un ensemble de commandes, décrites dans le RFC 1036, vous permettraient de dialoguer avec le serveur et aussi de lire et de poster dans les forums Usenet de cette façon. Conclusion Si l'étape n°1 et l'étape n°2 sont concluantes, les problèmes que vous rencontrez sont certainement liés à une mauvaise configuration des logiciels que vous utilisez, il faut faire une vérification (identifiant, mot de passe, paramètre, etc.). Étape n° 3 : si l'application de cette trousse de secours n'a pas fait avancer d'un pouce votre situation, pas de panique, la bonne réponse est 42. :) Annexes Pour découvrir les commandes reconnues par un service via le mode telnet, voici quelques RFC. Les RFC sont des documents publics, décrivant les standards de l'Internet. Ils sont disponibles sur de nombreux serveurs FTP comme celui de l'INRIA (ftp.inria.fr). RFC 821 - Simple Mail Transfer Protocol RFC 1651 - SMTP Service Extensions RFC 1939 - Post Office Protocol - version 3 RFC 2060 - Internet Message Access Protocol - version 4revl RFC 1035 - Standard for Interchange of Usenet Messages RFC 977 - Network News Transfer Protocol
|