ip_conntrack_tcp_timeout_established не се прилага към цялата подмрежа

Имам nat настройка с хиляди устройства, свързани към нея. Шлюзът има своя интернет, осигурен от eth0, а устройствата от страната на LAN се свързват към eth1 на шлюза.

Имам следната настройка с 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 е конфигуриран както следва:

    ip: 192.168.0.1
subnet: 255.255.0.0

На клиентите се присвояват ip 192.168.0.2 до 192.168.255.254.

В /etc/sysctl.conf имам следната настройка за ip_conntrack_tcp_timeout_established

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=1200

Поради броя на клиентските устройства, които се свързват с този шлюз, не мога да използвам 5-дневното изчакване по подразбиране.

Това изглежда работи добре и тествахме настройката с над 10 000 клиентски устройства.

Проблемът, който виждам обаче, е, че установеното tcp изчакване от 1200 се прилага само към устройства в обхвата на ip от 192.168.0.2 до 192.168.0.255. Всички устройства с ips в диапазона 192.168.1.x до 192.168.255.x все още използват 5-дневното време за изчакване по подразбиране.

Това оставя твърде много „УСТАНОВЕНИ“ връзки в таблицата /proc/net/ip_conntrack и в крайна сметка тя се запълва, въпреки че трябва да изтекат в рамките на 20 минути, те показват, че ще изтекат след 5 дни.

Очевидно ми липсва някъде настройка или имам нещо неправилно конфигурирано.

Някакви предположения?

Благодаря


gateway timeout nat subnet iptables
person Stephen Hankinson    schedule 17.02.2012    source източник
comment
+1 за добър въпрос, но вероятно по-добре адресиран от хората на serverfault.com   -  person Adam Liss    schedule 17.02.2012
comment
Само в случай, че някой друг има подобен проблем. По принцип инсталирах conntrack_tools и стартирах sudo /usr/sbin/conntrack -F, за да нулирам таблицата и след това изглежда, че всички връзки започнаха да използват времето за изчакване от 1200 s вместо 5-дневното изчакване.   -  person Stephen Hankinson    schedule 17.02.2012

Отговори (1)


arrow_upward
4
arrow_downward

Както @StephenHankinson споменава, съществуващите връзки (вж. conntrack -L) по време на промяна на променливата sysctl нямат нулиране на времето за изчакване. Това обикновено не би трябвало да е проблем, тъй като тези връзки в крайна сметка ще прекратят, но NFCT може да бъде принуден да забрави всички CT, използвайки conntrack -F. Имайте предвид обаче, че това може да убие съществуващите връзки, ако вашият набор от правила не позволява „НОВИ“ връзки, които не започват с TCP SYN.

person jørgensen    schedule 20.02.2012