LINUX.ORG.RU
ФорумAdmin

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


0

0

Из-за чего оно может произходить:

/var/log/syslog:

Feb 24 10:25:56 sam-gw kernel: ip_conntrack: table full, dropping packet.

все это происходит на шлюзе под спутниковый инет. На машине почти ничего не вертиться. Настроена сеть, спутниковый инет, фаервол, и запущен globax (прокси-сервер). Железо описано ниже.

значение в /proc/sys/net/ipv4/ip_conntrack_max увеличил до 8192 через три дня (а не через день, как раньше) работы опять началось, пока машину не ребутнул. Потом даже до 16384 увеличил.

в теме http://www.linux.org.ru/jump-message.jsp?msgid=1284395 уже обсуждалось данная проблема. Только там выяснили, что произошло, а не почему это произошло.

OS: Slackware 10.1

Железо: корпус с источником питания, материнка, CPU pI-150 Mhz, MEM 32 Mb, hdd 544 Mb, Ethernet RTL-8139, DVB карта SkyStar2 (rev 2.6 d). Больше ничего нет.

★★

еще вот в этой доке 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]. Этот флаг сообщает о том, что соединение установлено уверенно и эта запись не будет стерта по достижении максимально возможного количества трассируемых соединений.

samson ★★
() автор топика
Ответ на: комментарий от samson

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

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

saper ★★★★★
()
Ответ на: комментарий от saper

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

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

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

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

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

samson ★★
() автор топика
Ответ на: комментарий от samson

спасёт 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 режиме

anonymous
()
Ответ на: комментарий от anonymous

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

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

samson ★★
() автор топика
Ответ на: комментарий от samson

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

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

saper ★★★★★
()
Ответ на: комментарий от saper

когда пробывал вышепосоветанное, в 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:~#

samson ★★
() автор топика
Ответ на: комментарий от samson

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 в самом деле запущены?

saper ★★★★★
()
Ответ на: комментарий от saper

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

samson ★★
() автор топика
Ответ на: комментарий от saper

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

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

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

samson ★★
() автор топика
Ответ на: комментарий от samson

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

saper ★★★★★
()
Ответ на: комментарий от saper

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

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

samson ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.