Lorsque les systèmes rencontrent des problèmes, comme cela arrive parfois, vous devez savoir comment résoudre le problème et les ramener à un état normal et fonctionnel. Dans cette section, nous nous concentrons sur les compétences fondamentales de dépannage réseau que tout administrateur de systèmes Linux devrait avoir.
Compréhension fondamentale du dépannage réseau
Dans la plupart des cas, il y a un grand fossé entre les administrateurs réseau et les administrateurs système. Les administrateurs système qui manquent de visibilité 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 qui manquent de connaissances sur les serveurs blâmeront souvent les administrateurs système pour les défaillances des périphériques finaux. Cependant, le jeu de la culpabilité n’aide pas à résoudre les problèmes et dans un environnement de travail, cela peut antagoniser les relations entre collègues.
En tant qu’administrateur système, avoir une compréhension fondamentale du dépannage réseau vous aidera à résoudre les problèmes plus rapidement et à promouvoir un environnement de travail cohésif. C’est pour cette raison que nous avons rassemblé cette section pour mettre en lumière quelques-uns des conseils de base en matière de dépannage réseau qui seront utiles lors du diagnostic des problèmes liés au réseau.
A Recap of the TCP / IP Model
Dans notre sujet précédent de la série LFCA, nous avons examiné le modèle conceptuel TCP/IP qui montre la transmission de données dans un ordinateur et les protocoles que l’on trouve à chaque couche.
Un autre modèle conceptuel tout aussi important est le modèle OSI (Open Systems Interconnection). Il s’agit d’un cadre de 7 couches TCP/IP qui décompose un système de réseau, et les fonctions informatiques sont présentes à chaque couche.
Dans le modèle OSI, ces fonctions sont segmentées dans les couches suivantes, à commencer par le bas : Couche physique, Couche liaison de données, Couche réseau, Couche transport, Couche session, Couche présentation, et enfin, la Couche application au sommet.
Il est impossible de parler de la détection et du résolution des problèmes de réseau sans faire référence au modèle OSI. C’est pourquoi, nous vous guiderons à travers chaque couche et découvrirons les divers protocoles de réseau utilisés et comment résoudre les défaillances associées à chaque couche.
Couche 1 : Couche physique
C’est probablement la couche la moins prise en compte, et pourtant, c’est l’une des couches les plus essentielles pour que toute communication puisse avoir lieu. La Couche physique englobe les composants réseau matériels d’un ordinateur tels que les cartes réseau, les câbles Ethernet, les fibres optiques, etc. La plupart des problèmes commencent ici et sont généralement 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 :
- “Le câble réseau est-il branché ?”
- “La connexion réseau physique est-elle établie ?”
- “Avez-vous une adresse IP ?”
- “Pouvez-vous faire un ping vers l’adresse IP de votre passerelle par défaut ?”
- “Pouvez-vous faire un ping vers votre serveur DNS ?”
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 à partir de la sortie que l’état de l’interface est UP.
Si une interface réseau est inactive, vous verrez la sortie DOWN.
Si c’est le cas, vous pouvez activer l’interface à l’aide de la commande suivante :
$ sudo ip link set enp0s3 up
Alternativement, vous pouvez exécuter la commande ifconfig ci-dessous.
$ sudo ifconfig enp0s3 up $ ip link show
Pour confirmer que votre PC a récupéré une adresse IP du routeur ou du serveur DHCP, exécutez la commande ifconfig.
$ ifconfig
L’adresse IPv4 est précédée du paramètre inet comme indiqué. Par exemple, l’adresse IP de ce système est 192.168.2.104 avec un masque de sous-réseau ou une adresse nette de 255.255.255.0.
$ ifconfig
Alternativement, vous pouvez 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 dans la plupart des cas est le serveur DHCP ou le routeur, est indiquée comme illustré ci-dessous. Dans un réseau IP, vous devriez pouvoir effectuer un ping sur 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
A better way to check the DNS servers in use is to run the nmcli command shown
$ ( nmcli dev list || nmcli dev show ) 2>/dev/null | grep DNS
Comme vous l’avez observé, une grande partie du dépannage réseau se déroule ici.
Couche 2 : Couche 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 la communication des trames de données entre les hôtes a lieu. Le protocole prédominant dans cette couche est le ARP ( Protocole de résolution d’adresses).
ARP est responsable de la découverte des adresses de couche liaison et effectue le mappage des adresses IPv4 sur la couche 3 aux adresses MAC. Généralement, lorsqu’un hôte contacte la passerelle par défaut, il a déjà l’adresse IP de l’hôte, mais pas les adresses MAC.
Le protocole ARP comble l’écart entre la couche 3 et la couche 2 en traduisant les adresses IPv4 de 32 bits de la couche 3 en adresses MAC de 48 bits de la couche 2 et vice versa.
Lorsqu’un PC rejoint un réseau LAN, le routeur (la passerelle par défaut) lui attribue une adresse IP à des fins d’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 correspondant à 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 remarquer, l’adresse MAC du routeur est renseignée. En cas de problème de résolution, la commande ne renvoie aucun résultat.
Couche 3 : Couche réseau / Internet
C’est la couche avec laquelle vous travaillez exclusivement avec les adresses IPv4 que les administrateurs système connaissent bien. Elle fournit plusieurs protocoles tels que ICMP et ARP que nous avons abordés, ainsi que d’autres comme RIP (protocole d’information de routage, Routing Information Protocol).
Certains problèmes courants comprennent une mauvaise configuration des appareils ou des problèmes avec des dispositifs réseau tels que des routeurs et des commutateurs. Un bon point de départ pour le dépannage est de vérifier si votre système a bien récupéré 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. Le drapeau -c indique le nombre de paquets envoyés.
$ ping 8.8.8.8 -c 4
La sortie montre une réponse positive du DNS de Google sans perte de paquets. Si vous rencontrez une connexion intermittente, vous pouvez vérifier le point où les paquets sont perdus en utilisant la commande traceroute comme suit.
$ traceroute google.com
Les astérisques indiquent le point où les paquets sont perdus.
La commande nslookup interroge le DNS pour obtenir l’adresse IP associée à un domaine ou à un nom d’hôte. Ceci est appelé une recherche DNS avant.
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 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 de transport gère la transmission des données en utilisant les protocoles TCP et UDP. Pour récapituler, TCP est un protocole orienté connexion tandis que UDP est sans connexion. Les applications en cours d’exécution écoutent sur des sockets qui comprennent des ports et des adresses IP.
Les problèmes courants qui peuvent survenir comprennent les ports TCP bloqués, qui peuvent être requis par les applications. Si vous avez un serveur web et que vous voulez vérifier son état de fonctionnement, utilisez la commande netstat ou ss pour vérifier si le service web écoute sur 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 voulez qu’un autre service utilise ce port, vous pourriez être contraint de 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 du dépannage se fera à travers ces 4 couches. Très peu de dépannage est effectué dans les couches de session, de présentation et d’application. C’est parce qu’elles jouent un rôle moins actif dans le fonctionnement d’un réseau. Cependant, jetons rapidement un coup d’œil à ce qui se passe dans ces couches.
Couche 5: Couche de session
La couche de session ouvre des canaux de communication appelés sessions et garantit qu’ils restent ouverts pendant la transmission des données. Elle les ferme également une fois la communication terminée.
Couche 6 : Couche de présentation
Aussi connue sous le nom de couche de syntaxe, la couche de présentation synthétise les données à utiliser par la couche d’application. Elle spécifie comment les appareils doivent crypter, encoder et compresser les données dans le but de garantir qu’elles sont bien reçues à l’autre extrémité.
Couche 7 : Couche d’application
Enfin, nous avons la couche d’application qui est la plus proche des utilisateurs finaux et leur permet d’interagir avec le logiciel d’application. La couche d’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 des informations sur ce qui ne va pas et vous aide à cerner le problème.
Source:
https://www.tecmint.com/basic-network-troubleshooting-tips/