2012-02-17 18 views
6

Tengo una configuración nat con miles de dispositivos conectados a ella. La puerta de enlace tiene su internet provisto por eth0 y los dispositivos en el lado LAN se conectan a eth1 en la puerta de enlace.ip_conntrack_tcp_timeout_established no se aplica a toda la subred

que tienen la siguiente configuración con iptables:

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT 
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT 

eth1 está configurado de la siguiente manera:

ip: 192.168.0.1 
subnet: 255.255.0.0 

clientes se les asigna el IPS a través de 192.168.0.2 192.168.255.254.

En /etc/sysctl.conf que tienen la siguiente configuración para ip_conntrack_tcp_timeout_established

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=1200 

Debido al gran número de dispositivos de cliente que se conectan a esta pasarela no puedo usar el día 5 tiempo de espera predeterminado.

Esto parece funcionar bien y ha probado la configuración con más de 10000 dispositivos cliente.

Sin embargo, el problema que estoy viendo es que el tcp establecido tiempo de espera de 1200 solo se aplica a dispositivos en el rango de ip de 192.168.0.2 a 192.168.0.255. Todos los dispositivos con ips en el rango de 192.168.1.x a 192.168.255.x todavía usan el tiempo de espera predeterminado de 5 días.

Esto está dejando demasiadas conexiones "ESTABLECIDAS" en la tabla/proc/net/ip_conntrack y eventualmente se llena, aunque deberían agotar el tiempo en 20 minutos, muestran que se agotarán en 5 días .

Obviamente me falta un ajuste en alguna parte o tengo algo configurado incorrectamente.

¿Alguna sugerencia?

Gracias

+0

+1 para una buena pregunta, pero probablemente sea mejor tratada por la gente en serverfault.com –

+4

Solo en caso de que alguien más tenga un problema similar. Básicamente instalé conntrack_tools y ejecuté sudo/usr/sbin/conntrack -F para restablecer la tabla y después de eso todas las conexiones parecían comenzar a usar el tiempo de espera de 1200 en lugar del tiempo de espera de 5 días. –

Respuesta

3

Como se menciona @StephenHankinson, las conexiones existentes (cf. conntrack -L) en el momento de cambiar la variable sysctl no tienen su reinicio de tiempo de espera. Esto normalmente no debería ser un problema, ya que estas conexiones terminarán eventualmente, pero NFCT puede verse obligado a olvidar todos los CTs usando conntrack -F. Sin embargo, tenga en cuenta que esto podría matar conexiones existentes si su conjunto de reglas no permite conexiones "NUEVAS" que no comiencen con TCP SYN.

Cuestiones relacionadas