Algunos parámetros del kernel modificables mediante sysctl

Este artículo pretende recopilar y documentar algunos de los parámetros útiles para la optimización del kernel de Linux, que pueden establecerse sea temporalmente escribiendo en los archivos de /proc/sys/net/ o mediante el comando sysctl -w parametro=valor, o también de manera persistente editando el archivo /etc/sysctl.conf o los archivos en el subdirectorio /etc/sysctl.d/ (puede que no exista en algunas distribuciones).

Tabla de parámetros

Parámetro	Valor predeterminado	Valor recomendado	Observaciones	Relevancia
net.ipv4.ip_forward	0	1	Habilitar el reenvío de paquetes, necesario para el NAT.¹⁾	Alta
net.ipv6.conf.all.disable_ipv6	0	1	De momento en Cuba no se está utilizando IPv6, deshabilitarlo puede evitar un consumo de recursos innecesario en un servidor de prestaciones limitadas.	Baja
net.ipv6.conf.default.disable_ipv6	0	1	Idem.	Baja
net.ipv4.conf.all.accept_redirects	1	0	Normalmente habilitar las redirecciones ICMP se considera un riesgo de seguridad.	Media
net.ipv4.conf.all.log_martians	0	1	Registrar los paquetes que parecen salir de la nada (marcianos).	Baja
net.ipv4.tcp_syncookies	0	1	Evitar los ataques de inundación SYN.	Media
net.ipv4.tcp_max_syn_backlog	1024	2048	Cantidad de peticiones SYN a mantener en memoria que aun no hayan recibido ACK por parte del cliente. No incrementar mucho si se posee poca RAM. Se supone que un valor de 1024 es para 128 MiB de RAM o superior.	Baja
net.ipv4.tcp_tw_recycle	0	1	Habilitar el reciclaje rápido de los sockets TIME_WAIT. Puede ayudar en el caso de muchos paquetes que permanezcan en dicho estado llenando la tabla de rastreo de conexiones.	Media
net.ipv4.tcp_tw_reuse	0	1	Habilitar la reutilización de los sockets TIME_WAIT. Complementa la preferencia anterior.	Media
net.ipv4.tcp_timestamps	1	0	Deshabilitar las marcas de tiempo en las conexiones TCP puede ayudar en las redes lentas, ya que de estar habilitadas se agregan 10 bytes a cada paquete.	Media
net.ipv4.tcp_rmem	4096 87380 6291456	?	Tamaño mínimo, predeterminado y máximo (en bytes) de los búferes de recepción TCP.	Media
net.ipv4.tcp_wmem	4096 16384 4194304	?	Idem de los búferes de transmisión TCP.	Media
net.ipv4.tcp_syn_retries	5	6	Cantidad de reintentos de envío del paquete SYN para establecer una nueva conexión, si no se recibe una respuesta (cada intento demora el doble de tiempo que el anterior, comenzando por 3 segundos). Es recomendable mantenerlo entre 4 y 8. Bajo ninguna circunstancia debe ser mayor de 255.	Media
net.ipv4.tcp_synack_retries	5	5	Complementa la preferencia anterior, establece los reintentos de transmisión de la respuesta SYN/ACK a un paquete SYN, en otras palabras, cuántas veces reintentar establecer una conexión pasiva iniciada por otro equipo. Puede ser útil reducirla a 4 ó 3 si se sospecha que nos realizan un ataque de denegación de servicios.	Media
net.netfilter.nf_conntrack_icmp_timeout	30?	20	Tiempo de espera (en segundos) para las conexiones ICMP.	Baja
net.netfilter.nf_conntrack_tcp_timeout_syn_recv	60	60	Tiempo de espera (en segundos) para el estado SYN-RECEIVED, al cual se entra de los estados LISTEN o SYN-SENT una vez que el servidor recibe un paquete SYN y responde con SYN/ACK. Cuando el servidor recibe el ACK final del 3-way handshake, se pasa al estado ESTABLISHED. Generalmente es desaconsejable reducirlo.	Media
net.netfilter.nf_conntrack_tcp_timeout_syn_sent	120	?	Tiempo de espera (en segundos) que el cliente permanece en estado SYN-SENT una vez enviado el paquete SYN y se espera el SYN/ACK. Si la comunicación se estanca, puede ser útil subir el valor; bajarlo para reducir las entradas en la tabla de rastreo de conexiones es desaconsejable.	Media
net.netfilter.nf_conntrack_tcp_timeout_established	432000	86400	TTL (en segundos) para las conexiones establecidas. Puede reducirse más aun si no se pretende permitir conexiones persistentes de larga duración.	Alta
net.netfilter.nf_conntrack_tcp_timeout_fin_wait	120	?	Tiempo de espera (en segundos) para los estados FIN_WAIT. Se entra a FIN_WAIT1 cuando el servidor envía un paquete FIN, y a FIN_WAIT2 cuando el servidor recibe como respuesta FIN/ACK. Si el servidor recibe FIN mientras espera aun FIN/ACK, entra directamente en el estado CLOSE.	Alta
net.netfilter.nf_conntrack_tcp_timeout_close_wait	43200	?	Tiempo de espera (en segundos) en el estado CLOSE_WAIT, al cual se entra después que el cliente recibe un paquete FIN y responde con FIN/ACK. El estado CLOSE_WAIT se mantiene hasta que el cliente envía el paquete FIN final, y entonces la conexión pasa a LAST_ACK.	Alta
net.netfilter.nf_conntrack_tcp_timeout_last_ack	30	?	Tiempo de espera (en segundos) para entrar en el estado LAST_ACK, que sigue a CLOSE_WAIT y termina cuando se recibe el FIN/ACK final en respuesta al último FIN del cliente, tras lo cual el rastreo de conexiones se destruye y se pasa al estado CLOSED.	Alta
net.netfilter.nf_conntrack_tcp_timeout_close	10	?	Tiempo de espera del estado CLOSE, al cual se entra si el cliente envía FIN y recibe FIN del servidor, y responde con FIN/ACK. El estado CLOSE se mantiene mientras se espera el FIN/ACK de respuesta, cuando llega, se entra en TIME_WAIT.	Alta
net.netfilter.nf_conntrack_tcp_timeout_time_wait	120	20	Tiempo de espera (en segundos) del estado TIME_WAIT, que es el último posible en una conexión TCP. Cuando expira, se destruye la entrada en el rastreo de conexiones y se entra al estado CLOSED.	Alta
net.ipv4.netfilter.ip_conntrack_udp_timeout	30	?	Tiempo de espera inicial (en segundos) para las conexiones UDP. Cuando un paquete UDP enviado ha recibido respuesta entra en el estado ESTABLISHED, de continuar el tráfico se considera un stream. Si se utilizan protocolos que intercambian poca información en un lapso de tiempo largo, puede ser necesario elevar este valor. Reducirlo es generalmente desaconsejable.	Baja
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream	180	?	Tiempo de espera (en segundos) para los streams UDP (tales como intercambio de voz o video). Si se tienen problemas con conexiones UDP que expiran muy pronto, puede ser útil elevar este valor. Reducirlo es desaconsejable.	Baja
net.netfilter.nf_conntrack_generic_timeout	600	?	Tiempo de espera genérico (en segundos) para el rastreo de conexiones, en caso de no poder determinarse el protocolo utilizado.	Media
net.ipv4.ip_local_port_range	32768 61000	?	Contiene el rango de puertos efimeros que se usarán de forma aleatorea para crear conexiones TCP. Para servidores con una gran carga de conexiones (Web, email, etc) puede ser recomendable aumentarlo.	Baja
net.ipv4.tcp_keepalive_time	7200	1800²⁾	Tiempo que se mantendrán las conexiones TCP inactivas. Conviene reducirlo en servidores de gran carga.	Media
net.ipv4.icmp_echo_ignore_broadcasts	1	1	Evitar que el comando ping pueda enviarse a la dirección de difusión de una red (esto crearía una congestión inútil).	Alta

Gráfico de estados TCP

Para ilustrar un poco mejor la relación entre los diferentes estados por los que transitan los paquetes con el protocolo TCP, incluímos el siguiente gráfico.³⁾

Notas

La mayoría de las distribuciones propone una configuración que suele funcionar de manera estable y razonablemente eficiente para la generalidad de los casos. Modificar dicha configuración sin conocer lo que se está haciendo puede tener resultados contraproducentes.

Referencia

Atribuciones

Autor: Hugo Florentino
Colaboradores: Ulises González
(Gráfico tomado de http://i.stack.imgur.com/SVAZq.gif)

¹⁾

Para minimizar el risgo de vulnerabilidades, se recomienda establecer en netfilter una política de denegación por defecto para la cadena FORWARD.

²⁾

Recomendación de IBM

³⁾

Puede que el gráfico no resulte fácil de entender, pero al menos muestra los estados, y servirá en lo que aparezca uno mejor.

Wiki GUTL

Herramientas de usuario

Herramientas del sitio

Tabla de Contenidos