Vérifier l’accessibilité d’un serveur, d’un site ou d’un poste en mode « console ».

Il est peu arriver qu’un site Internet, le poste de votre voisin de bureau, votre FTP, ou un serveur SMTP, ne réponde pas. Vous pouvez obtenir différents types erreurs, de la fameuse 404 page not found, à d’autres explicitant plus ou moins clairement des problèmes situés entre votre poste, et ce que vous cherchez à joindre.


Le blocage peut être dû à votre réseau local, aux connexions entre votre réseau local, et Internet, ou bien à l’entité que vous tentez de joindre. Ciblez où se situe le blocage est un bon début, afin de pouvoir agir, ou faire remonter l’information, aux personnes appropriées.

Pour en savoir plus, il est bon de dénigrer l’interface graphique du navigateur, ou du logiciel que vous utilisez, qui se contente d’interpréter les erreurs bas niveaux, dans un langage plus « humain » pour un utilisateur lambda.
Intervient alors la console, fenêtre caractéristique de quelqu’un qui « s’y connaît » en informatique, pour celui qui trouve le langage binaire beaucoup trop étrange. On pense donc à la fenêtre DOS pour les férus de Windows, la console, appelée Terminal (et ses dérivés) sous les OS du noyau Linux, ainsi que sur Mac.

Via cet outil bicolore, vous pouvez lancer les commandes bas-niveaux, qui sont physiquement effectuées par n’importe qu’elle interface graphique grand public.

La commande la plus basique est un « ping », terme connu par un grand nombre de possesseurs de matériels informatique, sans compétences très approfondies.
Elle permet de vérifier si un hôte (un hôte désigne un système informatique distant que vous tentez de joindre) est en état de répondre ou non.

La commande se lance ainsi :

ping 'nomdhote'

Par exemple

ping www.google.com

Ceci permet de vérifier si le moteur de recherche est en état de marche actuellement.
Le résultat vous indique si l’hôte est joignable, et si des paquets sont perdus (problème de connectivité plus ou moins important entre les infrastructures)
Un temps de réponse est également indiqué, et il doit être inférieure à 100ms pour considérer la liaison comme « bonne »

ping www.google.fr
PING www-cctld.l.google.com (173.194.34.31) 56(84) bytes of data.
64 bytes from par03s02-in-f31.1e100.net (173.194.34.31): icmp_seq=1 ttl=52 time=18.0 ms
64 bytes from par03s02-in-f31.1e100.net (173.194.34.31): icmp_seq=2 ttl=52 time=17.5 ms
64 bytes from par03s02-in-f31.1e100.net (173.194.34.31): icmp_seq=3 ttl=52 time=17.9 ms
64 bytes from par03s02-in-f31.1e100.net (173.194.34.31): icmp_seq=4 ttl=52 time=17.8 ms
--- www-cctld.l.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 17.573/17.860/18.040/0.203 ms

Attention! Certains hôtes peuvent interdire les tentatives de ping, ce qui fait que votre requête n’aboutira pas. Vous pourrez donc penser à un problème de joignabilité de l’hôte.

Une commande plus puissante, du nom de Telnet entre en jeu. Toujours accessible dans l’environnement de type console, elle permet de tester l’accessibilité sur un certain port. Les ports les plus connus étant :

  • 80 pour une requête HTTP
  • 443 pour une requête HTTPS
  • 22 pour une connexion SSH
  • 110 pour relever des mails en POP3
  • 143 pour consulter sa boîte mail en IMAP4
  • 25 ou 587 pour envoyer un mail (protocole SMTP)
  • 21 pour un FTP
  • 6667 pour IRC

La commande Telnet se lance donc ainsi:

telnet nomdhote port

Par exemple

telnet smtp.alinto.net 587

ou

telnet www.google.fr 80

Si vous obtenez seulement comme résultat un « Trying… », soit votre paramétrage réseau ne permet pas de joindre l’hôte avec le port indiqué, soit c’est l’hôte qui refuse les connexions avec le port en question.

Si vous avez une réponse instantanée, du type

Trying 173.194.34.23...
Connected to www-cctld.l.google.com.
Escape character is '^]'.

ou

Trying 83.145.109.171...
Connected to smtp.alinto.net.
Escape character is '^]'.

Cela signifie que la connexion a abouti correctement. Une fois connecté, vous pouvez alors lancer une commande du protocole, mais la connexion est bien établie
Dans ce cas, toute erreur qui surviendrait via une interface graphique est causé par une règle, configuration, ou dysfonctionnement sur l’hôte distant.

Ces erreurs ou règles sont référencées, pour les plus courantes

L’ensemble des commandes relatives au mail ( POP/IMAP/SMTP…) peuvent être intégralement testés via Telnet, et cela peut expliciter un bon nombre d’erreurs que vous pourriez obtenir lors de l’utilisation d’un client de messagerie du marché. Mais cela dépasse le cadre de cet article, nous y reviendrons plus tard.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *