Conexiones huérfanas en estado CLOSE_WAIT

Tengo una máquina SLES que acumula conexiones TCP en un estado CLOSE_WAIT durante lo que parece ser para siempre. Estos descriptores eventualmente absorben toda la memoria disponible. Por el momento, tengo 3037 de ellos, pero fue mucho mayor antes de un reinicio apresurado recientemente.

Lo interesante es que no provienen de conexiones a puertos locales que espero tengan procesos de escucha. No tienen PID asociados, y sus temporizadores parecen haber expirado.

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -     

No soy un cinturón negro cuando se trata de la pila TCP o la red del núcleo, pero la configuración TCP parece sensata, ya que estos valores son predeterminados, según la página del manual:

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

Entonces, ¿qué da? Si los temporizadores han expirado, ¿no debería la pila eliminar automáticamente todo esto? Efectivamente, me estoy dando un DoS a largo plazo a medida que estas cosas se acumulan.

No, no hay tiempo de espera para CLOSE_WAIT. Creo que eso es lo que offsignifica en su salida.

Para salir CLOSE_WAIT, la aplicación tiene que cerrar el socket explícitamente (o salir).

Ver Cómo romper CLOSE_WAIT .

Si netstatse muestra -en la columna de proceso:

• ¿Está ejecutando con los privilegios y capacidades adecuados (por ejemplo, como root)?
• Podrían ser procesos del núcleo (por ejemplo, nfsd)

CLOSE_WAITindica que el cliente está cerrando la conexión pero la aplicación aún no la ha cerrado o el cliente no. Debe identificar qué programa o programas tienen este problema. Intente usar netstat -tonp 2>&1 | grep CLOSEpara determinar qué programas mantienen las conexiones.

Si no hay programas en la lista, el kernel proporciona el servicio. Estos son probablemente servicios RPC como nfso rpc.lockd. Los servicios de kernel de escucha se pueden enumerar con netstat -lntp 2>&1 | grep -- -.

A menos que los servicios RPC se hayan vinculado a puertos fijos, se unirán a puertos efímeros a medida que sus conexiones aparezcan. También es posible que desee verificar los procesos y montajes en el otro servidor.

Puede vincular sus servicios NFS a puertos fijos haciendo lo siguiente:

1. Seleccione cuatro puertos no utilizados para NFS (32763-32766 usado aquí)
2. Agregue puertos fijos para NFS a /etc/services

   rpc.statd-bc 32763 / udp # RCP statd broadcast
   rpc.statd-bc 32763 / tcp
   rpc.statd 32764 / udp # RCP statd escuchar
   rpc.statd 32764 / tcp
   rpc.mountd 32765 / udp # RPC mountd
   rpc.mountd 32765 / tcp
   rpc.lockd 32766 / udp # RPC lockd / nlockmgr
   rpc.lockd 32766 / tcp

3. Configurar statd para usar las opciones --port 32763 --outgoing-port 32764
4. Configure rpcmountd para usar la opción --port 32765
5. Apague y reinicie los servicios NFS y RPC.