Quel processus Linux est chargé de répondre aux pings?

J'ai un contrôleur de processus basé sur Linux qui se verrouille de temps en temps au point où vous ne pouvez pas lui envoyer de requête ping (c.-à-d. Que je peux lui envoyer une requête ping, il ne devient plus pingable sans aucune modification des paramètres réseau).

Je suis curieux de savoir quel processus / système est responsable de la réponse aux pings? Il semble que ce processus se bloque.

network-interface ping icmp

— Izzo
source

Pouvez-vous toujours ssh dedans pendant qu'il ne répond pas aux pings? Ou les sessions SSH existantes sont-elles bloquées?

— Peter Cordes

@PeterCordes L'ensemble du système se bloque et est essentiellement une brique jusqu'au forçage du redémarrage.

— Izzo

Ok, c’est normalement le seul moyen pour une machine de ne plus répondre aux pings. Il serait étrange que les pings cessent de fonctionner, mais que d'autres éléments continuent de fonctionner, car la gestion des pings fonctionne même si l'espace utilisateur est limité et que tout est bloqué sur les E / S du disque sur un disque mort, un montage NFS ou autre. Essayez de connecter un moniteur à votre système et vérifiez s’il ya un message sur la console pendant son verrouillage. (Et si vous pouvez utiliser les séquences magiques du clavier SysRQ pour dump des informations, ou remonter en lecture seule, forcez la synchronisation des disques + redémarrez.

— Peter Cordes

Bien que votre question soit intéressante, le ping n'est pas la source des problèmes de votre système, mais plutôt la conséquence d'un système instable. Consultez les journaux pour comprendre ce qui ne va pas.

— Pedro Lobito

@PedroLobito Quels journaux en particulier?

— Izzo

Réponses:

La pile réseau du noyau gère les messages ICMP, qui sont ceux envoyés par le ping commande.

Si vous ne recevez pas de réponses, mis à part des problèmes de réseau ou de filtrage, filtrez-vous avec un hôte, limitez votre cadence de trafic / parcourez les frontières / etc. cela signifie que la machine est probablement surchargée par quelque chose qui peut être transitoire ou le noyau s’être écrasé, ce qui est rare mais peut arriver (matériel défectueux, etc.), pas nécessairement à cause du trafic ICMP (mais en essayant de le surcharger avec ce type de trafic). peut être un bon test au début de la vie d’un serveur pour voir comment il préserve les choses). Dans le dernier cas de plantage du noyau, vous devriez avoir de nombreuses informations dans les fichiers journaux ou sur la console.

Notez également qu’il pings’agit presque toujours du mauvais outil pour vérifier si un service est en ligne ou non. Pour diverses raisons, mais surtout parce qu'il ne reproduit pas, par définition, le trafic réel des applications. Par exemple, si vous devez vérifier qu'un serveur Web est toujours actif, vous devez lui adresser une requête HTTP (port TCP 80 ou 443). Si vous devez vérifier un serveur de messagerie, vous devez effectuer une requête SMTP (port TCP 25), si un serveur DNS, un UDP et une requête TCP sur le port 53, etc.

— Patrick Mevzek
source

@Outurnate Tout autre test de service d'application échouerait ou serait dans un délai d'attente afin que le résultat final observé soit le même. Je ne rate jamais une occasion de faire des leçons contre l'utilisation, pingcar cela crée beaucoup trop de faux positifs dans le dépannage. Je pense donc que les utilisateurs qui ne savent pas exactement ce que fait le ping et comment il peut donner des résultats trompeurs devraient s'en tenir à autre chose.

— Patrick Mevzek le

Dans la plupart des situations de surcharge, les seules choses qui répondent toujours sont celles effectuées par le noyau. Cela signifie qu'une machine répond habituellement au ping, quelle que soit sa surcharge. Les tentatives pour atteindre un port fermé répondront avec RST pour TCP et une erreur ICMP dans le cas du protocole UDP. Et les premières tentatives pour atteindre un port TCP ouvert complèteront une poignée de main. Une défaillance du disque peut entraîner à peu près les mêmes symptômes.

— Kasperd

@kasperd J'ai vu des serveurs (très) surchargés (en particulier des serveurs d'échange) ne pas répondre aux requêtes ICMP. Et bien sûr, rien d’autre. Le noyau ne s'est pas écrasé, il était juste occupé par des opérations d'E / S de disque.

— Patrick Mevzek

@Nacht Yup. Une interface réseau est un périphérique matériel; en tant que tel, il y a un pilote de noyau pour l'interface avec celui-ci. Une deuxième couche fournit ensuite des API génériques de gestion / communication. (Ceci n'est pas propre aux réseaux: il existe ALSA pour les devs audio, les sorties vidéo utilisent l'API KMS, l'USB a {U, E, X} HCI, puis usb_storage, usbhid, etc.) Tables de routage réseau, règles de pare-feu (via iptables ), handshaking, assemblage de paquets, retransmissions, etc. sont tous dans le noyau. Comme ICMP est un protocole en soi, sans charge utile ni traitement allant au-delà de "répondre ou ne pas répondre", le noyau traite directement les réponses ICMP pour un surcoût minimal.

— FeRD

@Nacht: Il ne s'agit pas vraiment d'architecture informatique fondamentale; c'est un choix d'implémentation. Microkernels traitera ICMP dans un processus de système d'exploitation.

— MSalters

Il n'y a pas de processus utilisateur qui soit responsable de la réponse aux pings. Ping est juste un utilitaire pour envoyer des paquets d'écho ICMP. Ceux-ci sont reçus et traités par la pile réseau du noyau.

— Renvoyer
source

Le noyau lui - même (aucun processus utilisateur) est responsable d'envoyer écho ICMP réponse des messages en réponse à la demande de ICMP messages. Ainsi, si un hôte cesse de répondre aux pings, cela est généralement dû à l'une des raisons suivantes:

la connectivité réseau entre vous et l'hôte auquel vous envoyez une requête ping a peut-être été interrompue. Cela peut être dû à des tonnes de raisons: dommages matériels aux câbles, bruit dans le cas du sans fil, tableaux de route brisés, attaques DDoS, routeurs / commutateurs problématiques entre deux, etc. Dans ce cas, le dépannage commence par en utilisant ethtool(8), iwconfig(8), route(8), ping(8)son routeur, tcpdump(8)etc. sur l' hôte cible.
La configuration du pare-feu sur l'hôte cible (ou tout routeur / pare-feu entre vous et l'hôte cible) peut limiter le nombre de pings (ou la quantité de trafic). Cela pourrait également être dû à des outils tels que le fail2ban(8)pare-feu à la demande. Voir iptables(8)pour vérifier.
il y a eu un dysfonctionnement logiciel / matériel sur l'hôte cible. Le module de noyau réseau sur l’hôte cible peut avoir une erreur OOPSed et / ou devenir confus, ou même un noyau entier peut avoir PANICked. Vous verrez apparaître des messages dmesg(8)sur l'hôte cible ou sur l'écran de la console physique (si l'accès physique n'est pas pratique, un autre ordinateur doté d' une console série peut vous aider.) Si le problème réside dans le noyau OOPS / PANIC, il peut arriver aide, ou vous pouvez vous calmer autour des blocages du système avec les watchdog(8)pilotes auxiliaires. Ou vous pouvez changer des pièces de matériel.

— Matija Nalis
source

Pour les intéressés, voici le code de noyau pertinent pour la gestion des demandes d'écho ICMP.

— Ruslan

il faut aussi mentionner la charge très élevée (spécialement l'unité centrale)

— Guilherme Bernal

@GuilhermeBernal Non, même une charge utilisateur extrêmement élevée (en milliers) ne provoquera pas de perte ICMP (car elle est servie dans le noyau, avant que les processus utilisateur ne puissent s'exécuter). Un taux de PPS réseau extrêmement élevé, associé à du matériel bas de gamme, peut entraîner une perte de paquets, mais ce type de DDoS entre dans la catégorie "connectivité réseau"

— Matija Nalis