Le serveur est en panne: comment savoir ce qui ne va pas? – Serveur d’impression

Cet article est extrait du livre Dépannage de DevOps: pratiques recommandées pour les serveurs Linux et est reproduit avec l'autorisation de l'éditeur Pearson / Addison-Wesley Professional.

De nombreux problèmes différents peuvent apparaître sur un réseau. Par conséquent, les compétences en matière de dépannage réseau sont essentielles pour les responsables de serveurs ou de services sur des serveurs connectés à un réseau. Linux fournit un vaste ensemble d'outils de dépannage réseau. Cet article décrit quelques problèmes réseau courants et explique comment utiliser certains des outils disponibles sous Linux pour en identifier la cause.

Problème: le serveur A ne peut pas parler au serveur B

Le scénario de dépannage réseau le plus courant implique probablement l’impossibilité pour un serveur de communiquer avec un autre serveur du réseau. Cette section utilisera un exemple dans lequel un serveur nommé dev1 ne peut pas accéder au service Web (port 80) sur un deuxième serveur nommé web1. Ceci peut être dû à un certain nombre de problèmes différents. Nous allons donc exécuter étape par étape des tests que vous pouvez effectuer pour isoler la cause du problème.

Normalement, lorsque vous résolvez un problème de ce type, vous pouvez ignorer certaines de ces étapes initiales (telles que la vérification du lien), car des tests ultérieurs les excluront également. Par exemple, si vous testez et confirmez que DNS fonctionne, vous avez prouvé que votre hôte peut communiquer sur le réseau local. Pour cet exemple, cependant, nous allons passer en revue chaque étape intermédiaire pour illustrer comment vous pouvez tester chaque niveau.

Problème client ou serveur?

Un test rapide que vous pouvez effectuer pour déterminer la cause de votre problème consiste à contacter un autre hôte du même réseau et à essayer d'accéder au serveur. Dans cet exemple, vous devriez trouver un autre serveur sur le même réseau que dev1, tel que dev2, et essayer d'accéder à web1. Si dev2 ne peut pas non plus accéder à web1, vous savez que le problème est plus susceptible de se produire sur web1 ou sur le réseau entre dev1, dev2 et web1. Si dev2 peut accéder à web1, alors vous savez que le problème est plus probable sur dev1. Pour commencer, supposons que dev2 puisse accéder à web1, nous allons donc concentrer notre dépannage sur dev1.

Est-il branché?

Les premières étapes de dépannage à effectuer sont sur le client. Vous voulez d'abord vérifier que la connexion de votre client au réseau est saine. Pour ce faire, vous pouvez utiliser le programme ethtool (installé via le paquet ethtool) pour vérifier que votre liaison est active (le périphérique Ethernet est connecté physiquement au réseau). Si vous ne savez pas quelle interface vous utilisez, lancez la commande / sbin / ifconfig commande pour répertorier toutes les interfaces réseau disponibles et leurs paramètres. Donc, si votre périphérique Ethernet était à eth0