Dépannage et débogage du réseau Linux

De temps en temps, les utilisateurs de Linux et Unix sont confrontés à divers problèmes de réseau. Beaucoup de ces problèmes sont présentés ici et sur d'autres forums de dépannage, mais ils sont très concrets et contiennent de nombreuses informations techniques supplémentaires, et il est parfois difficile de comprendre le point principal et la véritable raison du comportement du système buggy.

En posant cette question, mon intention est de démarrer une page wiki de communauté qui permet de généraliser notre expérience de dépannage et de débogage sur le réseau. J'espère que les utilisateurs de Linux et Unix pourront plus facilement identifier et résoudre ("diviser pour régner") leurs problèmes de réseau en utilisant cette page.

Le parent de cette page devrait être la meilleure pratique pour diagnostiquer les problèmes . Mais ici, nous devrions nous concentrer sur la résolution des problèmes de réseau à partir de l’ espace utilisateur / noyau.

Je suppose que si vous:

1. Partagez les informations sur l'utilisation d'un outil de diagnostic réseau de qualité avec des exemples d'utilisation concrets et des exemples de bugs réseau, qu'ils aident à résoudre.
2. Partagez le lien vers l'excellent tutoriel réseau lié à ce sujet.
3. Parler d'une méthode générale ou d'une recette qui permet de s'attaquer à une classe de problèmes de réseau
4. Partagez des informations sur votre ensemble d'outils pour le débogage et le dépannage du réseau

cela conviendrait parfaitement pour ce sujet.

Je vais commencer par partager le lien vers les outils de diagnostic varios et un tutoriel simple de 12 ans . Le tutoriel archlinux semble également avoir des informations réelles sur notre sujet. Et pour plonger dans les réseaux Linux, nous devons absolument visiter Linux Networking-HOWTO .

Je pense que les principes généraux du dépannage réseau sont les suivants:

1. Déterminez à quel niveau de la pile TCP / IP (ou une autre pile) se pose le problème.
2. Comprendre quel est le comportement correct du système et quel est l'écart par rapport à l'état normal du système
3. Essayez d'exprimer le problème en une phrase ou en plusieurs mots
4. En utilisant les informations obtenues du système de buggy, votre propre expérience et l'expérience d'autres personnes (google, forum divers, etc.), essayez de résoudre le problème jusqu'à la réussite (ou l'échec).
5. Si vous échouez, demandez de l'aide à d'autres personnes ou des conseils.

Quant à moi, j'obtiens généralement toutes les informations requises à l'aide de tous les outils nécessaires, et j'essaie de faire correspondre ces informations à mon expérience. Décider quel niveau de pile réseau contient le bogue aide à éliminer les variantes improbables. Utiliser l’expérience d’autres personnes aide à résoudre les problèmes rapidement, mais cela peut souvent conduire à penser que je peux résoudre un problème sans le comprendre et que si ce problème se reproduit, il m’est impossible de le résoudre à nouveau sans Internet.

Et en général, je ne sais pas comment résoudre les problèmes de réseau. Il semble qu'il y ait une fonction magique dans mon cerveau nommée SolveNetworkProblem(information_about_system_state, my_experience, people_experience), qui peut parfois donner exactement la bonne réponse, mais aussi parfois échouer (comme ici, TCP meurt sur un ordinateur portable Linux ).

J'utilise habituellement les utilitaires de cet ensemble pour le débogage du réseau:

• ifconfig(ou ip link, ip addr) - pour obtenir des informations sur les interfaces réseau
• ping- pour la validation, si l'hôte cible est accessible depuis ma machine. pingCela pourrait également être utilisé pour les diagnostics DNS de base - nous pourrions envoyer une requête ping à l’hôte par adresse IP ou par son nom d’hôte, puis décider si le DNS fonctionne ou non. Et ensuite tracerouteou tracepathou mtrregarder ce qui se passe sur le chemin.
• dig - diagnostiquer tout DNS
• dmesg | lessou dmesg | tailou dmesg | grep -i error- pour comprendre ce que le noyau Linux pense de certains problèmes.
• netstat -antp+ | grep smth- mon utilisation la plus populaire de la commande netstat, qui affiche des informations sur les connexions TCP. Souvent, j'effectue un filtrage à l'aide de grep. Voir aussi la nouvelle sscommande (de iproute2la nouvelle suite standard d'outils de réseau Linux) et en lsoftant que lsof -ai tcp -c some-cmd.
• telnet <host> <port> - est très utile pour communiquer avec divers services TCP (par exemple, sur les protocoles SMTP, HTTP), nous pourrions également vérifier l’opportunité générale de se connecter à un port TCP.
• iptables-save(sous Linux) - pour vider les tables iptables complètes
• ethtool - récupère tous les paramètres de la carte d'interface réseau (statut de la liaison, vitesse, paramètres de déchargement ...)
• socat- l'outil suisse d'armée pour tester tous les protocoles réseau (UDP, multicast, SCTP ...). Particulièrement utile (plus que telnet) avec quelques -doptions.
• iperf - tester la disponibilité de la bande passante
• openssl( s_client, ocsp, x509...) pour déboguer tous les problèmes SSL / TLS / PKI.
• wireshark - le puissant outil de capture et d’analyse du trafic réseau, qui vous permet d’analyser et d’attraper de nombreux bugs réseau.
• iftop - montrer les gros utilisateurs sur le réseau / routeur.
• iptstate (sous Linux) - vue actuelle du suivi de connexion du pare-feu.
• arp(ou le nouveau (Linux) ip neigh) - affiche l'état de la table ARP.
• routeou le plus récent (sous Linux) ip route- affiche l'état de la table de routage.
• strace(ou truss, dtraceou tuscselon le système) - est un outil utile qui indique quels appels système traite le problème, il affiche également des codes d'erreur (errno) lorsque les appels système échouent. Ces informations en disent souvent assez pour comprendre le comportement du système et résoudre un problème. Vous pouvez également utiliser des points d'arrêt sur certaines fonctions de réseau gdbpour savoir quand ils sont créés et avec quels arguments.
• examiner les problèmes de pare-feu sous Linux: iptables -nvLindique le nombre de paquets correspondant à chaque règle ( iptables -Zpour mettre les compteurs à zéro). La LOGcible insérée dans les chaînes de pare-feu est utile pour voir quels paquets les atteignent et comment ils ont déjà été transformés. Pour aller plus loin NFLOG(associé à ulogd), vous enregistrerez le paquet complet.

Un nombre surprenant de "problèmes de réseau" se résument à des problèmes de DNS d'un type ou d'un autre. Le dépannage initial doit être utilisé ping -n w.x.y.zpour laisser de côté la résolution DNS du nom d’hôte et pour vérifier la connectivité IP. Après cela, utilisez route -npour vérifier la route IP par défaut sans résolution DNS.

Après avoir vérifié la connectivité IP et routage, nslookup, hostet digpeut donner des informations. N'oubliez pas que le "verrouillage" peut indiquer que des délais d'attente DNS sont en train de se produire.

N'oubliez pas de vérifier l'existence et le contenu de /etc/resolv.conf. Les clients DHCP modifient ce fichier à chaque bail, et parfois, ils se trompent ou, si l'espace disque est restreint, une mise à jour risque de ne pas se produire.

Des problèmes de câblage peuvent exister. Si vous avez accès au matériel, assurez-vous que les câbles sont tous branchés et engagés mécaniquement. Si vous pouvez voir des routeurs ou des interfaces Ethernet, assurez-vous que les voyants de liaison sont allumés.

À distance, vous devez compter sur ethtoolet mii-tool.

[root@flask ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 24
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x00000001 (1)
                               drv
        Link detected: yes

"Lien détecté: oui", c'est bien, mais 10 Mo / s et Demi-duplex ne sont pas bons, car la carte réseau de cet ordinateur peut faire mieux. Je dois savoir si la carte réseau est gaffée ou le câble est. Un autre ordinateur branché sur le même routeur indique 100 Mbits / s, duplex intégral.