Gran cantidad de conexiones TIME_WAIT dice netstat

28

De acuerdo, esto me está asustando: veo alrededor de 1500-2500 de estos:

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

Ese número está cambiando rápidamente.

Tengo una configuración de iptables bastante ajustada, así que no tengo idea de qué puede causar esto. ¿algunas ideas?

Gracias,

Tamas

Editar: Salida de '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   -
linux networking debian tcpip netstat KTamas
fuente
1
¿Tiene algo NFS montado en la misma máquina que lo está exportando?
Paul Tomblin
@Paul Tomblin: No.
KTamas
1
Bueno, deberías mirar las conexiones establecidas para saber qué programa es. "rcpinfo -p" también puede ayudar a descubrir qué se está comunicando con portmapper.
cstamas
Para aquellos que encuentran su camino aquí mientras intentan encontrar una forma de ajustar el retraso en Windows, se puede hacer a través de una configuración de registro .
Synetech

Respuestas:

22

EDITAR: tcp_fin_timeout NO controla la duración de TIME_WAIT, está codificado a 60 segundos

Como han mencionado otros, tener algunas conexiones TIME_WAITes una parte normal de la conexión TCP. Puede ver el intervalo examinando /proc/sys/net/ipv4/tcp_fin_timeout:

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

Y cámbielo modificando ese valor:

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

O permanentemente agregándolo a /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Además, si no utiliza el servicio RPC o NFS, puede desactivarlo:

/etc/init.d/nfsd stop

Y apágalo completamente

chkconfig nfsd off
Brandon
fuente
sí, mi script ipconfig ya lo reduce a 30. No tengo nfsd en /etc/init.d/, pero tenía portmap ejecutándose, lo detuve, ahora TIME_WAITs se redujo a unas pocas instancias (1-5). Gracias.
KTamas
18
Uhh, tcp_fin_timeout no tiene nada que ver con los sockets en el estado time_wait. Eso afecta a fin_wait_2.
diq
2
+1 para el comentario de diq. No están relacionados
mcauth
1
Correcto ... puede ver la cuenta regresiva de los sockets desde 60 incluso si se cambia tcp_fin_timeout usandoss --numeric -o state time-wait dst 10.0.0.100
Greg Bray
16

TIME_WAIT es normal. Es un estado después de que se cierra un socket, utilizado por el kernel para realizar un seguimiento de los paquetes que pueden haberse perdido y haber llegado tarde a la fiesta. Una gran cantidad de conexiones TIME_WAIT es un síntoma de obtener muchas conexiones de corta duración, no hay nada de qué preocuparse.

David Pashley
fuente
Esta respuesta es corta y dulce. Esto ayuda mucho. La última oración me confundió un poco, pero creo que el punto es que debes entender por qué se están creando tantas conexiones. Si está escribiendo un cliente que genera muchas solicitudes, probablemente desee asegurarse de que esté configurado para reutilizar las conexiones existentes en lugar de crear conexiones nuevas para cada solicitud.
nobar
Sudor corto, no completo. TIME_WAITs dependen del contexto. Si tiene muchos de ellos, es posible que alguien esté atacando su servidor.
Mindaugas Bernatavičius
5

No es importante Todo lo que significa es que está abriendo y cerrando muchas conexiones TCP Sun RCP (1500-2500 de ellas cada 2-4 minutos). El TIME_WAITestado es en lo que entra un socket cuando se cierra, para evitar que lleguen mensajes para las aplicaciones incorrectas como lo harían si el socket se reutilizara demasiado rápido, y para un par de otros propósitos útiles. No te preocupes por eso.

(A menos que, por supuesto, en realidad no esté ejecutando nada que deba procesar tantas operaciones RCP. Entonces, se preocupe).

caos
fuente
Ejecuto courier-imap y postfix, principalmente.
KTamas
4

Algo en su sistema está haciendo muchas RPC (Llamadas de procedimiento remoto) dentro de su sistema (observe que tanto el origen como el destino son localhost). Eso se ve a menudo para lockd para montajes NFS, pero también puede verlo para otras llamadas RPC como rpc.statd o rpc.spray.

Puede intentar usar "lsof -i" para ver quién tiene esos sockets abiertos y ver qué lo está haciendo. Probablemente sea inofensivo.

Paul Tomblin
fuente
Nada inusual allí, veo un TCP *: sunrpc (LISTEN) para portmap pero supongo que es normal.
KTamas
Sigue haciéndolo repetidamente hasta que veas quién está abriendo la conexión.
Paul Tomblin
netstat -epn --tcp le mostrará la misma información. A menos que esté usando NFS, probablemente tenga muy pocas razones para usar portmap. Podrías eliminarlo.
David Pashley
De hecho, no uso NFS, sin embargo apt-get remove portmap quiere eliminar 'fam' que fue instalado automáticamente probablemente por libfam0 que fue instalado por courier-imap. apt-cache dice que 'fam' es un paquete recomendado para libfam0.
KTamas
2

tcp_fin_timeoutNO controla el TIME_WAITretraso. Puede ver esto usando ss o netstat con -o para ver los temporizadores de cuenta regresiva:

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)

incluso con tcp_fin_timeout configurado en 3, la cuenta regresiva para TIME_WAIT aún comienza en 60. Sin embargo, si tiene net.ipv4.tcp_tw_reuse configurado en 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), el núcleo puede reutilizar sockets en TIME_WAIT si determina que no habrá posibles conflictos en TCP Numeración de segmentos.

Greg Bray
fuente
1

Yo también tuve el mismo problema. Me costó varias horas averiguar qué está pasando. En mi caso, la razón de esto fue que netstat intenta buscar el nombre de host correspondiente a la IP (supongo que está usando la API gethostbyaddr). Estaba usando una instalación de Linux incorporada que no tenía /etc/nsswitch.conf. Para mi sorpresa, el problema solo existe cuando realmente estás haciendo un netstat -a (lo descubriste ejecutando portmap en modo detallado y de depuración).

Ahora, lo que sucedió fue lo siguiente: Por defecto, las funciones de búsqueda también intentan contactar al demonio ypbind (Sun Yellow Pages, también conocido como NIS) para consultar un nombre de host. Para consultar este servicio, se debe contactar al portmapper portmap para obtener el puerto para este servicio. Ahora el portmapper en mi caso fue contactado a través de TCP. Portmapper le dice a la función libc que no existe tal servicio y que la conexión TCP se cierra. Como sabemos, las conexiones TCP cerradas entran en un estado TIME_WAIT por algún tiempo. Entonces, netstat detecta esta conexión cuando se enumera y esta nueva línea con una nueva IP emite una nueva solicitud que genera una nueva conexión en el estado TIME_WAIT y así sucesivamente ...

Para resolver este problema, cree un /etc/nsswitch.conf que no utilice los servicios rpc NIS, es decir, con los siguientes contenidos:

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