Quale processo Linux è responsabile della risposta ai ping?

Ho un controller di processo basato su Linux che occasionalmente si blocca fino al punto in cui non è possibile eseguire il ping (ovvero posso eseguire il ping, quindi non diventa più eseguibile il ping senza modifiche alle impostazioni di rete).

Sono curioso, quale processo / sistema è responsabile per rispondere effettivamente ai ping? Sembra che questo processo si blocchi.

network-interface ping icmp

— Izzo
fonte

Puoi ancora parlarci mentre non risponde ai ping? O le sessioni SSH esistenti si bloccano?

— Peter Cordes,

@PeterCordes L'intero sistema si blocca ed è essenzialmente un mattone fino a forzare un riavvio.

— Izzo,

Ok, questo è normalmente l'unico modo in cui una macchina smetterà di rispondere ai ping. Sarebbe strano se i ping smettessero di funzionare ma altre cose continuassero a funzionare, perché la gestione del ping funziona anche se lo spazio utente è nascosto e tutto è bloccato sull'I / O del disco su un disco morto o su un montaggio NFS o altro. Prova a collegare un monitor al tuo sistema e vedi se c'è un messaggio della console mentre si blocca. (E se puoi usare le magiche sequenze di tasti della tastiera SysRQ per scaricare informazioni o rimontarlo di sola lettura, sincronizza forzatamente i dischi + riavvia.

— Peter Cordes

Mentre la tua domanda è interessante, il ping non è la fonte dei problemi del tuo sistema, ma piuttosto una conseguenza di un sistema instabile. Controlla i log per capire cosa c'è che non va.

— Pedro Lobito,

@PedroLobito Cosa registra specificamente?

— Izzo,

Risposte:

Lo stack di rete del kernel gestisce i messaggi ICMP, che sono quelli inviati dal pingcomando.

Se non si ottengono risposte, oltre a problemi di rete o filtraggio, e filtraggio basato su host / limitazione della frequenza / black-holing / ecc. significa che la macchina è probabilmente sovraccarica di qualcosa, che può essere transitoria, o il kernel si è bloccato, cosa rara ma può accadere (hardware difettoso, ecc.), non necessariamente a causa del traffico ICMP (ma cercando di sovraccaricarlo con tale traffico può essere un buon test all'inizio della vita di un server per vedere come sostiene le cose). Nel caso successivo del crash del kernel dovresti avere ampie informazioni nei file di registro o sulla console.

Si noti inoltre che pingè quasi sempre lo strumento sbagliato per verificare se un servizio è online o meno. Per vari motivi, ma soprattutto perché non imita il traffico reale delle applicazioni, per definizione. Ad esempio, se è necessario verificare che un server Web sia ancora attivo, è necessario invece eseguire una query HTTP su di esso (porta TCP 80 o 443), se è necessario controllare un server di posta si esegue una query SMTP (porta TCP 25), se un server DNS, un UDP e una query TCP alla porta 53, ecc.

— Patrick Mevzek
fonte

@Utilizzare qualsiasi altro test del servizio applicativo fallirebbe o si troverebbe in un timeout, quindi il risultato finale osservato sarà lo stesso. Non ho mai perso l'occasione di tenere una lezione contro l'uso pingpoiché questo crea troppi falsi positivi nella risoluzione dei problemi, quindi penso che gli utenti che non sanno esattamente cosa fa il ping e come può dare risultati fuorvianti dovrebbero attenersi a qualcos'altro.

— Patrick Mevzek,

Nella maggior parte delle situazioni di sovraccarico le uniche cose che ancora rispondono sono quelle fatte dal kernel. Ciò significa che una macchina di solito risponde al ping indipendentemente da quanto sia sovraccarica. I tentativi di raggiungere una porta chiusa risponderanno con RST per TCP e un errore ICMP in caso di UDP. E i primi tentativi di raggiungere una porta TCP aperta completeranno una stretta di mano. Un errore del disco può portare praticamente agli stessi sintomi.

— Kasperd,

@kasperd Ho visto server (molto) sovraccarichi (scambiare quelli in modo specifico) che non rispondevano nemmeno alle richieste ICMP. E ovviamente anche a nient'altro. Il kernel non si è arrestato in modo anomalo, era solo occupato nelle cose di I / O del disco.

— Patrick Mevzek,

@Nacht Yup. Un'interfaccia di rete è un dispositivo HW; come tale c'è un driver del kernel per interfacciarsi con esso. Un secondo livello fornisce quindi API di gestione / comunicazione generiche. (Questo non è univoco per la rete: c'è ALSA per gli sviluppatori audio, le uscite video utilizzano l'API KMS, USB ha {U, E, X} HCI, quindi usb_storage, usbhid, ecc.) Tabelle di routing di rete, regole del firewall (via iptables ), handshaking, assemblaggio pacchetti, ritrasmissioni, ecc. sono tutti nel kernel. Poiché ICMP è un protocollo a sé stante, senza alcun payload e nessuna elaborazione oltre a "rispondere o no", il kernel gestisce le risposte ICMP direttamente per un sovraccarico minimo.

— FERD

@Nacht: In realtà non si tratta dell'architettura informatica fondamentale; è una scelta di implementazione. I microkernels gestiranno ICMP in un processo del sistema operativo.

— Salterio

Non esiste alcun processo di userland responsabile della risposta ai ping. Ping è solo un'utilità per inviare pacchetti di eco ICMP. Questi sono ricevuti ed elaborati dallo stack di rete del kernel

— Outurnate
fonte

Il kernel stesso (non alcun processo utente) è responsabile dell'invio di messaggi di risposta echo ICMP in risposta ai messaggi di richiesta echo ICMP . Quindi, se un host smette di rispondere ai ping, di solito è dovuto ad alcuni dei seguenti motivi:

la connettività di rete tra l'utente e l'host su cui è stato eseguito il ping potrebbe essere stata interrotta. Potrebbe essere dovuto a tonnellate di ragioni stesse: danni fisici ai cavi, rumore nel caso di wireless, tabelle di rotta interrotte, essere sotto attacco DDoS, router / switch problematici tra ecc. In questo caso inizieresti a risolvere i problemi utilizzando ethtool(8), iwconfig(8), route(8), ping(8)suo router, tcpdump(8)ecc su host di destinazione.
l'impostazione del firewall sull'host di destinazione (o qualsiasi router / firewall tra l'utente e l'host di destinazione) può limitare la quantità di ping (o la quantità di traffico del traffico). Potrebbe anche essere dovuto a strumenti come fail2ban(8)firewall su richiesta. Vedi iptables(8)per controllare.
si è verificato un malfunzionamento del software / hardware nell'host di destinazione. Il modulo del kernel di rete sull'host di destinazione potrebbe avere OOPSed e / o diventare confuso, o anche l'intero kernel potrebbe avere PANICked. Vedrai i messaggi di at in dmesg(8)sull'host di destinazione o come output dello schermo sulla console fisica (se l'accesso fisico non è pratico, un altro computer con console seriale può aiutare.) Se il problema è il kernel OOPS / PANIC, un kernel più recente con driver migliori potrebbe aiuto, oppure potresti aggirare i blocchi di sistema con i watchdog(8)driver di aiuto. Oppure puoi cambiare le parti hardware.

— Matija Nalis
fonte

Per gli interessati, ecco il codice kernel rilevante per la gestione delle richieste di eco ICMP.

— Ruslan,

dovresti anche menzionare un carico molto elevato (specialmente cpu)

— Guilherme Bernal

@GuilhermeBernal no, anche un carico utente della CPU estremamente elevato (in migliaia) non porterà alla perdita di ICMP (perché è servito nel kernel, prima che i processi dell'utente abbiano la possibilità di essere eseguiti). Una velocità PPS di rete estremamente elevata in combinazione con hardware di fascia bassa potrebbe causare la perdita di pacchetti, ma tale DDoS rientra nella categoria "connettività di rete"

— Matija Nalis,