2012-02-17 21 views
6

Ho una configurazione nat con migliaia di dispositivi collegati ad essa. Il gateway ha Internet fornito da eth0 e i dispositivi sul lato LAN si connettono a eth1 sul gateway.ip_conntrack_tcp_timeout_established non applicato all'intera sottorete

Ho la seguente configurazione 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 è configurato come segue:

ip: 192.168.0.1 
subnet: 255.255.0.0 

Clienti viene assegnato il 192.168.0.2 ips attraverso 192.168.255.254.

In /etc/sysctl.conf Ho la seguente configurazione per ip_conntrack_tcp_timeout_established

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=1200 

A causa del numero di dispositivi client che si collegano a questo gateway non posso usare il timeout predefinito di 5 giorni.

Questo sembra funzionare bene e ha testato l'installazione con oltre 10000 dispositivi client.

Tuttavia, il problema che sto vedendo è che il timeout stabilito di tcp di 1200 viene applicato solo ai dispositivi nell'intervallo IP da 192.168.0.2 a 192.168.0.255. Tutti i dispositivi con ips compresi tra 192.168.1.x e 192.168.255.x continuano a utilizzare il timeout predefinito di 5 giorni.

Questo lascia troppe connessioni "ESTABLISHED" nella tabella/proc/net/ip_conntrack e alla fine si riempie, anche se dovrebbero scadere entro 20 minuti, stanno mostrando che scadranno in 5 giorni .

Ovviamente mi manca un'impostazione da qualche parte o c'è qualcosa configurato in modo errato.

Qualche suggerimento?

Grazie

+0

+1 per una buona domanda, ma probabilmente indirizzata meglio dagli utenti su serverfault.com –

+4

Nel caso in cui qualcun altro abbia un problema simile. Fondamentalmente ho installato conntrack_tools e ho eseguito un sudo/usr/sbin/conntrack -F per reimpostare la tabella e dopo che tutte le connessioni sembravano iniziare a usare il timeout dei 1200 invece del timeout di 5 giorni. –

risposta

3

Come @StephenHankinson cita, le connessioni esistenti (cfr conntrack -L) al momento di cambiare la variabile sysctl non hanno il loro ripristino timeout. Questo normalmente non dovrebbe essere un problema, poiché queste connessioni finiranno, ma l'NFCT può essere costretto a dimenticare tutti i CT usando conntrack -F. Si noti tuttavia che questo potrebbe uccidere le connessioni esistenti se il proprio set di regole non consente connessioni "NUOVE" che non iniziano con TCP SYN.