web-dev-qa-db-fra.com

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

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

En posant cette question, mon intention est de démarrer un wiki communautaire page qui permet de généraliser notre expérience de dépannage et de débogage réseau. J'espère que les utilisateurs Linux et Unix pourraient plus facilement reconnaître et résoudre ("diviser et conquérir") leurs problèmes de réseau en utilisant cette page.

Le parent de cette page doit être Meilleure pratique pour diagnostiquer les problèmes . Mais ici, nous devons nous concentrer sur le dépannage des problèmes de réseau à partir de espace utilisateur et noyau.

Je suppose que si vous:

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

il conviendrait parfaitement à ce sujet.

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

linuxnetworkingdebuggingtroubleshooting
83
dr.

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

  1. Découvrez à quel niveau de pile TCP/IP (ou une autre pile) se produit le problème.
  2. Comprendre quel est le comportement correct du système et quelle est la déviation de 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 ou des conseils à d'autres personnes

Quant à moi, j'obtiens généralement toutes les informations requises en utilisant 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 rapidement les problèmes, mais cela conduit souvent à une situation, que je peux résoudre un problème sans sa compréhension et 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 pourrait parfois retourner exactement la bonne réponse, et pourrait également parfois échouer (comme ici TCP meurt sur un ordinateur portable Linux ).

J'utilise généralement les utilitaires de cet ensemble pour le débogage réseau:

  • ifconfig (ou ip link, ip addr) - pour obtenir des informations sur les interfaces réseau
  • ping - pour validation, si l'hôte cible est accessible depuis ma machine. ping peut également être utilisé pour les diagnostics DNS de base - nous pouvons 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. Et puis traceroute ou tracepath ou mtr pour voir ce qui se passe sur le chemin.
  • Dig - diagnostique tout DNS
  • dmesg | less ou dmesg | tail ou dmesg | grep -i error - pour comprendre ce que le noyau Linux pense d'un problème.
  • 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 commande ss (de iproute2 la nouvelle suite standard des outils de mise en réseau Linux) et lsof comme dans lsof -ai tcp -c some-cmd.
  • telnet <Host> <port> - est très utile pour communiquer avec divers services TCP (par exemple sur SMTP, protocoles HTTP), nous pourrions également vérifier l'opportunité générale de se connecter à certains ports TCP 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 (état de la liaison, vitesse, paramètres de déchargement ...)
  • socat - l'outil de l'armée suisse pour tester tous les protocoles réseau (UDP, multicast, SCTP ...). Particulièrement utile (plus que telnet) avec quelques -d options.
  • iperf - pour tester la disponibilité de la bande passante
  • openssl (s_client, ocsp, x509...) pour déboguer tous les problèmes SSL/TLS/PKI.
  • wireshark - l'outil puissant pour capturer et analyser le trafic réseau, qui vous permet d'analyser et de détecter de nombreux bogues réseau.
  • iftop - affiche les gros utilisateurs sur le réseau/routeur.
  • iptstate (sous Linux) - vue actuelle du suivi des connexions du pare-feu.
  • arp (ou le nouveau (Linux) ip neigh) - affiche l'état de la table ARP.
  • route ou la plus récente (sous Linux) ip route - affiche l'état de la table de routage.
  • strace (ou truss, dtrace ou tusc selon le système) - est un outil utile qui montre quels appels système fait le problème, il montre aussi 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. Alternativement, l'utilisation de points d'arrêt sur certaines fonctions de mise en réseau dans gdb peut vous permettre de savoir quand ils sont créés et avec quels arguments.
  • pour enquêter sur les problèmes de pare-feu sous Linux: iptables -nvL indique le nombre de paquets correspondant à chaque règle (iptables -Z pour remettre à zéro les compteurs). La cible LOG 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 lorsqu'ils y sont arrivés. Pour aller plus loin, NFLOG (associé à ulogd) enregistrera le paquet complet.
120
dr.

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

Après avoir vérifié la connectivité IP et le routage, nslookup, Host et Dig peuvent fournir des informations. N'oubliez pas que le "verrouillage" peut indiquer que des délais d'attente DNS se produisent.

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 peut ne pas se produire.

15
Bruce Ediger

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 dépendre de ethtool et 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 Half duplex ne sont pas bons, car le NIC sur cet ordinateur peut faire mieux. J'ai besoin de savoir si le NIC est gaffé ou le câble l'est. Un autre ordinateur branché sur le même routeur indique 100Mb/s, Full duplex.

8
Bruce Ediger