2012-02-17 12 views
6

Mam konfigurację nat z tysiącami podłączonych do niej urządzeń. Brama ma swój Internet dostarczony przez eth0, a urządzenia po stronie LAN łączą się z eth1 na bramie.ip_conntrack_tcp_timeout_established nie zastosowano do całej podsieci

Mam następującą konfigurację z 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 jest skonfigurowany w następujący sposób:

ip: 192.168.0.1 
subnet: 255.255.0.0 

Klienci noszą 192.168.0.2 ips przez 192.168.255.254.

W /etc/sysctl.conf Mam następujące ustawienia dla ip_conntrack_tcp_timeout_established

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=1200 

Ze względu na liczbę urządzeń klienckich, które łączą się z tej bramki nie mogę użyć dniowy limit czasu domyślnego 5.

Wygląda na to, że działa dobrze i przetestowało konfigurację z ponad 10 000 urządzeniami klienckimi.

Jednak widzę, że ustalony limit czasu tcp wynoszący 1200 jest stosowany tylko do urządzeń w zakresie ip od 192.168.0.2 do 192.168.0.255. Wszystkie urządzenia z ips w zakresie od 192.168.1.x do 192.168.255.x nadal korzystają z domyślnego limitu czasu 5 dni.

To zostawia zbyt wiele połączeń typu "ESTABLISHED" w tabeli/proc/net/ip_conntrack i ostatecznie się zapełni, mimo że powinny upłynąć w ciągu 20 minut, pokazują, że przekroczą limit czasu w ciągu 5 dni .

Oczywiście brakuje mi jakiegoś ustawienia lub mam coś skonfigurowanego niepoprawnie.

Wszelkie sugestie?

Dzięki

+0

+1 za dobre pytanie, ale prawdopodobnie lepiej zaadresowane przez ludzi na serverfault.com –

+4

Na wszelki wypadek ktoś ma podobny problem. Zasadniczo zainstalowałem conntrack_tools i uruchomiłem sudo/usr/sbin/conntrack -F, aby zresetować tabelę, a potem wszystkie połączenia zaczęły korzystać z limitu czasu 1200s zamiast 5-dniowego limitu czasu. –

Odpowiedz

3

Jak wspomina @StephenHankinson, istniejące połączenia (por conntrack -L) w momencie zmiany zmiennej sysctl nie mają limitu czasu resetu. Zwykle nie powinno to stanowić problemu, ponieważ połączenia te ostatecznie się skończą, ale NFCT może zostać zmuszone do zapomnienia wszystkich CT za pomocą conntrack -F. Zauważ jednak, że może to zabić istniejące połączenia, jeśli twój zestaw reguł nie zezwala na połączenia "NOWE", które nie zaczynają się od TCP SYN.

Powiązane problemy