переполнение таблици ip_conntrack

еще вот в этой доке http://www.opennet.ru/docs/RUS/iptables/#THECONNTRACKENTRIES накапал коече:

root@sam-gw:/etc/rc.d# cat /proc/net/ip_conntrack
tcp 6 357593 ESTABLISHED src=192.168.50.252 dst=65.254.254.50 sport=4663 dport=25 src=65.254.254.50 ...............
......................
много много много ....
......................
cat: /proc/net/ip_conntrack: No space left on device

смысл в том что 357593 (tcp 6 357593) -- это время жизни этой записи в секундах. те 357593/60/60/24 = 4 дня!!!

почему оно такое большое??? Нормально ли это?

Хотя для ASSURED напсано:

> После получения пакета ответа трассировщик снимет флаг [UNREPLIED] и заменит его флагом [ASSURED]. Этот флаг сообщает о том, что соединение установлено уверенно и эта запись не будет стерта по достижении максимально возможного количества трассируемых соединений.

Возможно спутниковый internet работает широковещательно, поэтому вы получаете не только свои пакеты, которыми и забивается conntrack.

Варианты решений:
1. Уменьшать таймауты через /proc/sys/net/ipv4/netfilter/* и увеличивать кол-во записей в таблице. Это не оптимальный вариант.
2. Сделать так, чтобы в conntrack вообще не попадали пакеты, адресованные не вашим IP, для этого придется использовать таблицу raw и действие NOTRACK (доступно в штатном 2.6.15).

Я тоже думаю, что причиной всему этому именно спутниковый инет. Но решения не знаю.

> Уменьшать таймауты через /proc/sys/net/ipv4/netfilter/*

а можно поподробнее? Или хотябы линк на доку.

> Сделать так, чтобы в conntrack вообще не попадали пакеты, адресованные не вашим IP, для этого придется использовать таблицу raw и действие NOTRACK (доступно в штатном 2.6.15).

А в 2.6.10 такое возможно? И еще, если используя iptables просто зарезать (DROP) все пакеты, приходящие на dvb0_0 с не моим destination-ip.

спасёт iptables -t raw -A PREROUTING -i dvb0_0 -d ! 192.168.x.x -j NOTRACK iptables -t raw -A PREROUTING -i dvb0_0 -d ! 192.168.x.x -j DROP или отказ от программ типа tcpdump в promisc режиме

еще раз огромное спасибо 7-ому саппорту спайсгейта. Но как писал в асе, так не работает. При добавлении этого в rc.iptables инет просто перестает работать.

может 192.168.x.x -- ИП dvb0_0, совсем не то о чем я думал. другими словами, может вместо 192.168.x.x надо прописывать не ИП интерфейса dvb0_0, хотя, помоему, это бред и именно этот ИП там и должен быть.

Если синтаксис правильный, то anonymous выше все правильно написал, возможно вам стоит обновить ядро и привести статистику iptables (iptables -vnL -t raw;iptables -vnL -t filter;iptables -vnL -t nat) при включенных таких правилах.

И что у вас еще в rc.iptables?

когда пробывал вышепосоветанное, в rc.iptables было 3 строчки:
первая - SNAT (для локалки), 2 и 3 - то что посоветовали.

плюс еще несколько строк которые сбрасывают цепочки и делают ACCEPT.

вот что iptables -L пишет:

root@sam-gw:~# iptables -vnL -t raw
Chain PREROUTING (policy ACCEPT 90962 packets, 18M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 NOTRACK    all  --  dvb0_0 *       0.0.0.0/0           !192.168.10.238
    0     0 DROP       all  --  dvb0_0 *       0.0.0.0/0           !192.168.10.238

Chain OUTPUT (policy ACCEPT 52946 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination
root@sam-gw:~# iptables -vnL -t filter
Chain INPUT (policy ACCEPT 84 packets, 6096 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 51 packets, 5612 bytes)
 pkts bytes target     prot opt in     out     source               destination
root@sam-gw:~# iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 3094 packets, 1551K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 337 packets, 127K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       all  --  *      *       192.168.50.0/24      0.0.0.0/0           to:192.168.44.152

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
root@sam-gw:~#

Chain PREROUTING (policy ACCEPT 90962 packets, 18M bytes)
pkts bytes target prot opt in out source destination
0 0 NOTRACK all -- dvb0_0 * 0.0.0.0/0 !192.168.10.238
0 0 DROP all -- dvb0_0 * 0.0.0.0/0 !192.168.10.238

Первое, что видно - пакеты проходят через PREROUTING (ненулевые счетчики), но добавленные правила не работают. Соответственно по моему мнению и по фактам пакеты должны ходить как и раньше, то есть добавление этих 2 правил ничего не меняет. Если так, то почему conntrack переполняется? Может у вас там snort или ids или tcpump в самом деле запущены?

root@sam-gw:~# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:02 init [3]
    2 ?        SN     0:01 [ksoftirqd/0]
    3 ?        S<     0:07 [events/0]
    4 ?        S<     0:00 [khelper]
   16 ?        S<     0:00 [kblockd/0]
   87 ?        S      0:00 [pdflush]
   88 ?        S      0:03 [pdflush]
   90 ?        S<     0:00 [aio/0]
   89 ?        S      0:01 [kswapd0]
  673 ?        S      0:00 [kseriod]
  720 ?        S<     0:00 [reiserfs/0]
  757 ?        S<s    0:00 udevd
  986 ?        Ss     0:13 /usr/sbin/syslogd
  989 ?        Ss     0:06 /usr/sbin/klogd -c 3 -x
 1070 ?        Ss     0:02 /usr/sbin/sshd
 1140 ?        S      0:00 /usr/sbin/crond -l10
 1142 ?        Ss     0:00 ./globax
 1144 tty1     Ss+    0:00 /sbin/agetty 38400 tty1 linux
 1145 ?        S      8:32 ./globax
 1340 ?        Ss     0:00 sshd: samson [priv]
 1344 ?        S      0:04 sshd: samson@pts/0
 1345 pts/0    Ss     0:00 -bash
 4677 pts/0    S      0:01 /bin/bash
 7231 pts/0    R+     0:00 ps ax

> Соответственно по моему мнению и по фактам пакеты должны ходить как и раньше, то есть добавление этих 2 правил ничего не меняет.

после добавления этих двух правил перестает инет работать (пинг не идет). Значит всеже чтото меняет.

ps: если уже не писал, то ядро 2.6.10, может в нем что не так?

Попробуйте и в самом деле обновить до какого-нибудь последнего, возможно есть особенности при работе с таблицей raw, попробуйте найти документацию по этому вопросу.

придется маяться копаться и потеть стуча по клаве молотком :)

всем спасибо за участие