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 d'autres forums de dépannage, mais ils sont très concrets et contiennent beaucoup d'informations techniques supplémentaires, et il est parfois assez difficile de comprendre le point principal et la véritable raison du comportement bogué du système.

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 pourront plus facilement reconnaître et résoudre ("diviser pour régner") leurs problèmes de réseau en utilisant cette page.

Le parent de cette page doit être Meilleures pratiques pour diagnostiquer les problèmes. Mais ici, nous devons nous concentrer sur le dépannage des problèmes de réseau depuis l'espace utilisateur et noyau.

Je suppose que si vous :

Partagez les informations sur l'utilisation d'excellents outils de diagnostic réseau avec des exemples d'utilisation concrets et des exemples de bogues réseau, qu'ils aident à détecter.
Partagez le lien vers l'excellent tutoriel de réseau lié à ce sujet
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
Partagez des informations sur votre ensemble d'outils pour le débogage et le dépannage du réseau

cela conviendrait parfaitement à ce sujet.

Je vais commencer par partager le lien vers divers outils de diagnostic et un tutoriel simple vieux de 12 ans. De plus, le didacticiel archlinux semble contenir des informations réelles sur notre sujet. Et pour plonger dans le réseau Linux, nous devons absolument visiter Linux Networking-HOWTO.

Réponse acceptée :

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

Découvrez à quel niveau de la pile TCP/IP (ou d'une autre pile) se produit le problème.
Comprendre quel est le comportement correct du système et quel est l'écart par rapport à l'état normal du système
Essayez d'exprimer le problème en une phrase ou en plusieurs mots
En utilisant les informations obtenues du système bogué, votre propre expérience et l'expérience d'autres personnes (google, divers forums, etc.), essayez de résoudre le problème jusqu'au succès (ou à l'échec)
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 les problèmes rapidement, mais cela conduit souvent à une situation où je peux résoudre un problème sans le comprendre 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 je résous 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 pouvait parfois renvoyer exactement la bonne réponse, et pouvait aussi 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 valider, si l'hôte cible est accessible depuis ma machine. ping Il pourrait également être utilisé pour les diagnostics DNS de base - nous pourrions envoyer un 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 regarder ce qui se passe sur le chemin.
dig – diagnostiquer tout DNS
dmesg | less ou dmesg | tail ou dmesg | grep -i error – pour comprendre ce que le noyau Linux pense de certains problèmes.
netstat -antp + | grep smth – mon utilisation la plus courante de la commande netstat, qui affiche des informations sur les connexions TCP. Souvent, j'effectue un filtrage à l'aide de grep. Voir aussi le nouveau ss commande (depuis iproute2 la nouvelle norme suite d'outils 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 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 le complet tables iptables
ethtool – obtenir tous les paramètres de la carte d'interface réseau (état du lien, débit, paramètres de déchargement…)
socat – l'outil de l'armée suisse pour tester tous les protocoles réseaux (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 de capture et d'analyse du trafic réseau, qui vous permet d'analyser et de détecter de nombreux bugs réseau.
iftop – afficher 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 le plus récent (sous Linux) ip route – afficher 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 traitent le problème, il affiche également les 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 mise en réseau dans gdb peut vous permettre de savoir quand elles sont faites et avec quels arguments.
pour enquêter sur les problèmes de pare-feu sous Linux :iptables -nvL montre combien de paquets correspondent à chaque règle (iptables -Z pour remettre les compteurs à zéro). Le LOG La cible 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 arrivent. Pour aller plus loin NFLOG (associé à ulogd ) enregistrera le paquet complet.

Connexes :Glob avec ordre numérique ?