Enorme quantità di connessioni TIME

28

Ok, questo mi sta spaventando - ne vedo circa 1500-2500:

root@wherever:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942

Quel numero sta cambiando rapidamente.

Ho una configurazione iptables piuttosto stretta, quindi non ho idea di cosa possa causare questo. qualche idea?

Grazie,

Tamas

Modifica: output di 'netstat -anp':

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -

— KTamas
fonte

1

Hai qualcosa di NFS montato sullo stesso computer che lo sta esportando?

— Paul Tomblin,

@Paul Tomblin: No.

— KTamas,

1

Bene, dovresti guardare le connessioni stabilite per scoprire quale programma è. "rcpinfo -p" può anche aiutare a scoprire cosa sta comunicando con portmapper.

— cstamas,

Per quelli che trovano la loro strada qui mentre cercano di trovare un modo per regolare il ritardo in Windows, può essere fatto tramite un'impostazione del registro .

— Synetech,

22

EDIT: tcp_fin_timeout NON controlla la durata di TIME_WAIT, è hardcoded a 60s

Come menzionato da altri, avere alcune connessioni TIME_WAITè una parte normale della connessione TCP. Puoi vedere l'intervallo esaminando /proc/sys/net/ipv4/tcp_fin_timeout:

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

E cambiarlo modificando quel valore:

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

O permanentemente aggiungendolo a /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Inoltre, se non si utilizza il servizio RPC o NFS, è possibile disattivarlo:

/etc/init.d/nfsd stop

E spegnilo completamente

chkconfig nfsd off

— Brandon
fonte

sì, il mio script ipconfig lo abbassa già a 30. Non ho nfsd in /etc/init.d/, ma avevo la portmap in esecuzione, l'ho fermato, ora i TIME_WAIT sono scesi in alcune istanze (1-5). Grazie.

— KTamas,

18

Uhh, tcp_fin_timeout non ha nulla a che fare con i socket nello stato time_wait. Ciò riguarda fin_wait_2.

— diq

2

+1 per il commento di diq. Non sono imparentati.

— mcauth,

1

Corretto ... puoi vedere il conto alla rovescia dei socket da 60 anche se tcp_fin_timeout viene cambiato usandoss --numeric -o state time-wait dst 10.0.0.100

— Greg Bray il

16

TIME_WAIT è normale. È uno stato dopo che un socket è stato chiuso, utilizzato dal kernel per tenere traccia dei pacchetti che potrebbero essersi persi e presentati in ritardo alla festa. Un numero elevato di connessioni TIME_WAIT è un sintomo di ottenere molte connessioni di breve durata, non nulla di cui preoccuparsi.

— David Pashley
fonte

Questa risposta è breve e dolce. Aiuta molto. L'ultima frase mi ha confuso un po ', ma penso che il punto sia che devi capire perché vengono create così tante connessioni. Se stai scrivendo un client che genera molte richieste, probabilmente vuoi assicurarti che sia configurato per riutilizzare le connessioni esistenti piuttosto che crearne di nuove per ogni richiesta.

— nobar

Sudore corto, non completo. TIME_WAIT dipende dal contesto. Se ne hai molti, potrebbe essere che qualcuno stia attaccando il tuo server.

— Mindaugas Bernatavičius,

5

Non è importante Tutto ciò significa che stai aprendo e chiudendo molte connessioni TCP Sun RCP (1500-2500 di esse ogni 2-4 minuti). Lo TIME_WAITstato è quello in cui entra un socket quando viene chiuso, per evitare che i messaggi arrivino per le applicazioni sbagliate come potrebbero fare se il socket fosse riutilizzato troppo rapidamente e per un paio di altri scopi utili. Non ti preoccupare.

(A meno che, ovviamente, non stiate eseguendo nulla che dovrebbe elaborare molte operazioni RCP. Quindi, preoccupatevi.)

— caos
fonte

Corro corriere-imap e postfix, per lo più.

— KTamas,

4

Qualcosa sul tuo sistema sta facendo un sacco di RPC (Remote Procedure Calls) all'interno del tuo sistema (nota che sia la sorgente che la destinazione sono localhost). Questo è spesso visto per lockd per i montaggi NFS, ma potresti anche vederlo per altre chiamate RPC come rpc.statd o rpc.spray.

Potresti provare a usare "lsof -i" per vedere chi ha quei socket aperti e vedere cosa lo sta facendo. Probabilmente è innocuo.

— Paul Tomblin
fonte

Niente di insolito lì, vedo un TCP *: sunrpc (LISTEN) per portmap ma suppongo sia normale.

— KTamas,

Continua a farlo ripetutamente fino a quando non vedi chi sta aprendo la connessione.

— Paul Tomblin,

netstat -epn --tcp mostrerà le stesse informazioni. A meno che tu non stia usando NFS, probabilmente hai pochissime ragioni per usare portmap. Potresti rimuoverlo.

— David Pashley,

In effetti non uso NFS, tuttavia apt-get remove portmap vuole rimuovere 'fam' che è stato installato automaticamente probabilmente da libfam0 che è stato installato da courier-imap. apt-cache dice che "fam" è un pacchetto raccomandato per libfam0.

— KTamas,

2

tcp_fin_timeoutNON controlla il TIME_WAITritardo. Puoi vederlo usando ss o netstat con -o per vedere i timer del conto alla rovescia:

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

anche con tcp_fin_timeout impostato su 3 il conto alla rovescia per TIME_WAIT inizia ancora a 60. Tuttavia se net.ipv4.tcp_tw_reuse è impostato su 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), il kernel può riutilizzare i socket in TIME_WAIT se determina che non ci saranno possibili conflitti in TCP numerazione dei segmenti.

— Greg Bray
fonte

1

Ho avuto anche lo stesso problema. Mi costano diverse ore per scoprire cosa sta succedendo. Nel mio caso, la ragione di ciò era che netstat cerca di cercare il nome host corrispondente all'IP (suppongo che stia usando l'API gethostbyaddr). Stavo usando un'installazione Linux incorporata che non aveva /etc/nsswitch.conf. Con mia sorpresa, il problema esiste solo quando stai effettivamente eseguendo un netstat -a (lo hai scoperto eseguendo portmap in modalità dettagliata e debug).

Ora quello che è successo è stato il seguente: Per impostazione predefinita, le funzioni di ricerca provano anche a contattare il demone ypbind (Sun Yellow Pages, noto anche come NIS) per richiedere un nome host. Per richiedere questo servizio, è necessario contattare la portmap portmap per ottenere la porta per questo servizio. Ora il portmapper nel mio caso è stato contattato tramite TCP. Il portmapper dice quindi alla funzione libc che non esiste tale servizio e la connessione TCP viene chiusa. Come sappiamo, le connessioni TCP chiuse entrano nello stato TIME_WAIT per qualche tempo. Quindi netstat rileva questa connessione quando elenca e questa nuova riga con un nuovo IP emette una nuova richiesta che genera una nuova connessione nello stato TIME_WAIT e così via ...

Per risolvere questo problema, creare un file /etc/nsswitch.conf che non utilizza i servizi NIS rpc, ovvero con i seguenti contenuti:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files

— leecher
fonte

Enorme quantità di connessioni TIME_WAIT dice netstat