LFCA : Apprenez les conseils de base de dépannage réseau – Partie 12
Lorsque les systèmes rencontrent des problèmes, comme c'est parfois le cas, vous devez savoir comment contourner le problème et les restaurer à un état normal et fonctionnel. Dans cette section, nous nous concentrons sur les compétences fondamentales de dépannage réseau que tout administrateur système Linux devrait posséder.
Compréhension fondamentale du dépannage réseau
Dans la plupart des cas, il existe un écart important entre les administrateurs réseau et les administrateurs système. Les administrateurs système manquant de visibilité sur le réseau blâmeront généralement les administrateurs réseau pour les pannes et les temps d'arrêt, tandis que les administrateurs réseau ayant une connaissance insuffisante du serveur rejetteront souvent la faute sur les administrateurs système pour la défaillance des périphériques de point final. Cependant, le jeu du blâme n’aide pas à résoudre les problèmes et, dans un environnement de travail, cela peut contrarier les relations entre collègues.
En tant qu'administrateur système, avoir une compréhension fondamentale du dépannage réseau aidera à résoudre les problèmes plus rapidement et à promouvoir un environnement de travail cohérent. C'est pour cette raison que nous avons rassemblé cette section pour mettre en évidence certains des conseils de dépannage de base du réseau qui vous seront utiles lors du diagnostic des problèmes liés au réseau.
Un récapitulatif du modèle TCP/IP
Dans notre précédent sujet de la série LFCA, nous avons examiné le modèle conceptuel TCP/IP qui montre la transmission des données dans un ordinateur et les protocoles que l'on trouve dans chaque couche.
Un autre modèle conceptuel tout aussi important est le modèle OSI (Open Systems Interconnection). Il s'agit d'un framework TCP/IP à 7 couches qui décompose un système de réseau et les fonctions informatiques de chaque couche.
Dans le modèle OSI, ces fonctions sont segmentées dans les couches suivantes en commençant par le bas. Couche physique, couche liaison de données, couche réseau, couche transport, couche session. Couche de présentation, et enfin couche d'application tout en haut.
Il est impossible de parler de dépannage réseau sans faire référence au modèle OSI. Pour cette raison, nous vous guiderons à travers chaque couche et découvrirons les différents protocoles réseau utilisés et comment dépanner les défauts associés à chaque couche.
Couche 1 : couche physique
Il s’agit probablement de l’une des couches les plus négligées, mais c’est pourtant l’une des couches les plus essentielles nécessaires à toute communication. La couche physique englobe les composants physiques de réseau d'un PC tels que les cartes réseau, les câbles Ethernet, les fibres optiques, etc. La plupart des problèmes commencent ici et sont principalement causés par :
- Câble réseau/Ethernet débranché
- Câble réseau/Ethernet endommagé
- Carte réseau manquante ou endommagée
Dans cette couche, les questions qui viennent à l’esprit sont :
Pour vérifier l'état de vos interfaces réseau, exécutez la commande ip :
ip link show
D’après la sortie ci-dessus, nous avons 2 interfaces. La première interface – lo – est l'adresse de bouclage et n'est généralement pas utilisée. L'interface réseau active qui fournit la connectivité au réseau et à Internet est l'interface enp0s3. Nous pouvons voir sur le résultat que l'état de l'interface est UP.
Si une interface réseau est en panne, vous verrez la sortie state DOWN.
Si tel est le cas, vous pouvez afficher l'interface à l'aide de la commande :
sudo ip link set enp0s3 up
Vous pouvez également exécuter la commande ifconfig indiquée ci-dessous.
sudo ifconfig enp0s3 up
ip link show
Juste pour confirmer que votre PC a choisi une adresse IP sur le routeur ou le serveur DHCP, exécutez la commande ifconfig.
ifconfig
L'adresse IPv4 est préfixée par le paramètre inet comme indiqué. Par exemple, l'adresse IP de ce système est 192.168.2.104 avec un sous-réseau ou un masque de réseau 255.255.255.0.
ifconfig
Vous pouvez également exécuter la commande ip address comme suit pour vérifier l'adresse IP de votre système.
ip address
Pour vérifier l'adresse IP de la passerelle par défaut, exécutez la commande :
ip route | grep default
L'adresse IP de la passerelle par défaut, qui est dans la plupart des cas le serveur ou le routeur DHCP, est indiquée comme indiqué ci-dessous. Dans un réseau IP, vous devriez pouvoir envoyer une requête ping à la passerelle par défaut.
Pour vérifier les serveurs DNS que vous utilisez, exécutez la commande suivante sur les systèmes systemd.
systemd-resolve --status
Une meilleure façon de vérifier les serveurs DNS utilisés consiste à exécuter la commande nmcli affichée
( nmcli dev list || nmcli dev show ) 2>/dev/null | grep DNS
Comme vous l'avez observé, une grande partie du dépannage du réseau se produit ici.
Couche 2 : couche de liaison de données
Essentiellement, la couche liaison de données détermine le format des données sur le réseau. C'est là que s'effectue la communication des trames de données entre les hôtes. Le protocole prédominant dans cette couche est le ARP ( Address Resolution Protocol).
ARP est responsable de la découverte des adresses de couche liaison et effectue le mappage des adresses IPv4 sur la couche 3 vers les adresses MAC. Habituellement, lorsqu'un hôte contacte la passerelle par défaut, il est probable qu'il dispose déjà de l'adresse IP de l'hôte, mais pas des adresses MAC.
Le protocole ARP comble le fossé entre la couche 3 et la couche 2 en traduisant les adresses IPv4 32 bits sur la couche 3 en adresses MAC 48 bits sur la couche 2 et vice versa.
Lorsqu'un PC rejoint un réseau LAN, le routeur ( passerelle par défaut ) lui attribue une adresse IP pour l'identification. Lorsqu'un autre hôte envoie un paquet de données destiné au PC à la passerelle par défaut, le routeur demande à ARP de rechercher l'adresse MAC qui va avec l'adresse IP.
Chaque système possède sa propre table ARP. Pour vérifier votre table ARP, exécutez la commande :
ip neighbor show
Comme vous pouvez le constater, l'adresse MAC du routeur est renseignée. S’il y a un problème de résolution, la commande ne renvoie aucune sortie.
Couche 3 : couche réseau/Internet
Il s'agit de la couche sur laquelle vous travaillez exclusivement avec des adresses IPv4 familières aux administrateurs système. Il fournit plusieurs protocoles tels que ICMP et ARP que nous avons abordés et d'autres tels que RIP (Routing Information Protocol ).
Certains des problèmes courants incluent une mauvaise configuration des périphériques ou des problèmes avec les périphériques réseau tels que les routeurs et les commutateurs. Un bon point de départ pour le dépannage consiste à vérifier si votre système a sélectionné une adresse IP comme suit :
ifconfig
Vous pouvez également utiliser la commande ping pour vérifier la connectivité Internet en envoyant un paquet d'écho ICMP au DNS de Google. L'indicateur -c indique le nombre de paquets envoyés.
ping 8.8.8.8 -c 4
Le résultat montre une réponse positive du DNS de Google sans perte de paquets. Si vous disposez d'une connexion intermittente, vous pouvez vérifier à quel point les paquets sont abandonnés à l'aide de la commande traceroute comme suit.
traceroute google.com
Les astérisques indiquent le point auquel les paquets sont abandonnés ou perdus.
La commande nslookup interroge le DNS pour obtenir l'adresse IP associée à un domaine ou un nom d'hôte. C'est ce qu'on appelle la recherche DNS directe.
Par exemple.
nslookup google.com
La commande révèle les adresses IP associées au domaine google.com.
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: google.com
Address: 142.250.192.14
Name: google.com
Address: 2404:6800:4009:828::200e
La commande dig est encore une autre commande utilisée pour interroger les serveurs DNS associés à un nom de domaine. Par exemple, pour interroger les serveurs de noms DNS, exécutez :
dig google.com
Couche 4 : couche de transport
La couche transport gère la transmission des données à l'aide des protocoles TCP et UDP. Pour récapituler, TCP est un protocole orienté connexion tandis qu'UDP est sans connexion. L'application en cours d'exécution écoute sur les sockets qui comprennent des ports et des adresses IP.
Problèmes courants pouvant survenir, notamment les ports TCP bloqués qui peuvent être requis par les applications. Si vous disposez d'un serveur Web et que vous souhaitez vérifier son état de fonctionnement, utilisez la commande netstat ou ss pour vérifier si le service Web écoute le port 80.
sudo netstat -pnltu | grep 80
OR
ss -pnltu | grep 80
Parfois, un port peut être utilisé par un service en cours d'exécution dans le système. Si vous souhaitez qu'un autre service utilise ce port, vous devrez peut-être le configurer pour utiliser un port différent.
Si vous rencontrez toujours des problèmes, vérifiez le pare-feu et vérifiez si le port qui vous intéresse est bloqué.
La plupart des dépannages se produiront sur ces 4 couches. Très peu de dépannages sont effectués dans les couches session, présentation et application. En effet, ils jouent un rôle moins actif dans le fonctionnement d'un réseau. Cependant, ayons rapidement un aperçu de ce qui se passe dans ces couches.
Couche 5 : couche de session
La couche session ouvre des canaux de communication appelés sessions et garantit qu'ils restent ouverts pendant la transmission des données. Il se ferme également une fois la communication terminée.
Couche 6 : couche de présentation
Également connue sous le nom de couche syntaxique, la couche présentation synthétise les données à utiliser par la couche application. Il explique comment les appareils doivent chiffrer, encoder et compresser les données dans le but de garantir qu'elles soient bien reçues à l'autre bout.
Couche 7 : couche d'application
Enfin, nous avons la couche applicative qui est la plus proche des utilisateurs finaux et leur permet d'interagir avec le logiciel applicatif. La couche application est riche en protocoles tels que HTTP, HTTPS, POP3, IMAP, DNS, RDP, SSH, SNMP et NTP, pour n'en citer que quelques-uns.
Conclusion
Lors du dépannage d'un système Linux, l'approche en couches utilisant le modèle OSI est fortement recommandée, en commençant par la couche inférieure. Cela vous donne un aperçu de ce qui ne va pas et vous aide à cibler le problème.