Cet article est extrait du livre DevOps Troubleshooting: Linux Server Best Practices et est reproduit avec la permission de l'éditeur Pearson / Addison-Wesley Professional.
De nombreux problèmes différents peuvent apparaître sur un réseau, de sorte que les compétences de dépannage du réseau deviennent cruciales pour toute personne responsable des serveurs ou des services sur les serveurs connectés à un réseau. Linux fournit un large éventail d'outils de dépannage réseau, et cet article décrit quelques problèmes de réseau courants ainsi que la façon d'utiliser certains des outils disponibles pour Linux pour rechercher la cause première.
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 qu'un serveur ne peut pas communiquer avec un autre serveur du réseau. Cette section utilise 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. Un certain nombre de problèmes différents peuvent provoquer cela, nous allons donc exécuter étape par étape les tests que vous pouvez effectuer pour isoler la cause du problème.
Normalement, lors du dépannage d'un problème comme celui-ci, vous pouvez ignorer quelques-unes de ces étapes initiales (telles que la vérification du lien), car les tests plus en aval 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 parcourir 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 identifier la cause de votre problème consiste à accéder à un autre hôte sur le même réseau et à essayer d'accéder au serveur. Dans cet exemple, vous trouverez un autre serveur sur le même réseau que dev1, tel que dev2, et essayez d'accéder à web1. Si dev2 ne peut pas non plus accéder à web1, vous savez que le problème est plus probable sur web1 ou sur le réseau entre dev1, dev2 et web1. Si dev2 peut accéder à web1, vous savez que le problème est plus probable sur dev1. Pour commencer, supposons que dev2 peut 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 package ethtool) pour vérifier que votre lien est actif (le périphérique Ethernet est physiquement connecté au réseau). Si vous n'êtes pas sûr de l'interface que vous utilisez, exécutez le / sbin / ifconfig pour répertorier toutes les interfaces réseau disponibles et leurs paramètres. Donc, si votre périphérique Ethernet était à eth0
$
sudo ethtool eth0Paramètres pour eth0:
Ports pris en charge: [ TP ]
Modes de liaison pris en charge: 10baseT / Half 10baseT / Full
100baseT / Half 100baseT / Full
1000baseT / Half 1000baseT / Full
Prend en charge la négociation automatique: Oui
Modes de liaison annoncés: 10baseT / Half 10baseT / Full
100baseT / Half 100baseT / Full
1000baseT / Half 1000baseT / Full
Négociation automatique annoncée: Oui
Vitesse: 100 Mo / s
Duplex: Complet
Port: paire torsadée
PHYADE: 0
Émetteur-récepteur: interne
Négociation automatique: activée
Prend en charge le réveil: pg
Réveil: d
Niveau de message actuel: 0x000000ff (255)
Lien détecté: oui
Ici, sur la dernière ligne, vous pouvez voir que Lien détecté est défini sur oui, donc dev1 est physiquement connecté au réseau. Si ce paramètre était défini sur non, vous devrez inspecter physiquement la connexion réseau de dev1 et vous assurer qu'elle était connectée. Puisqu'il est physiquement connecté, vous pouvez continuer.
Commentaires
Laisser un commentaire