форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Информационная безопасность (Public)
Изначальное сообщение		[ Отслеживать ]

"iptables съел мозг"

Сообщение от Alexander (??) on 14-Окт-08, 01:44

Коллеги, Как такое может быть: пакет еще присутствует в конце цепочки POSTROUTING таблицы mangle, но отсутствует в начале POSTROUTING таблицы nat? Т.е.: # iptables -t mangle -A POSTROUTING -s 10.1.1.1 -j LOG <в лог сыпятся записи> # iptables -t nat -I POSTROUTING 1 -s 10.1.1.1 -j LOG <ни одной записи в логе> iptables: v1.3.8 uname: Linux host.domain 2.6.20.20-2 #2 SMP Mon Oct 15 15:26:52 MSD 2007 i686 i686 i386 GNU/Linux

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "iptables съел мозг"

Сообщение от thehangedman (ok) on 14-Окт-08, 03:37

На ум приходят два варианта 1) В таблицу nat попадает только первый пакет потокового соединения, для остальных автоматически применяется то же действие - а через цепочки они не проходят. Но первый пакет все равно должен логироваться. 2) Может, чем черт не шутит, в ядре nat не включен? (не знаю, как в таком случае поведет себя iptables)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "iptables съел мозг"
	Сообщение от Alexander (??) on 14-Окт-08, 10:38
	А не может это быть как-то связано с переполнением внутренних таблиц? Может эти параметры как-то негативно влияют? net.ipv4.route.max_size=300000 net.ipv4.tcp_syncookies=1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.conf.eth0.accept_redirects = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.core.rmem_max=221184 net.core.wmem_max=221184 net.core.rmem_default=110592 net.core.wmem_default=110592 net.ipv4.tcp_rmem=4096 87380 174760 net.ipv4.tcp_wmem=4096 16384 131072 net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.default.arp_filter = 0 net.ipv4.conf.all.arp_announce=1 net.ipv4.conf.default.arp_announce=1 net.ipv4.conf.all.arp_ignore=2 net.ipv4.conf.default.arp_ignore=2 net.ipv4.tcp_timestamps=0 net.ipv4.icmp_ignore_bogus_error_responses=1 net.ipv4.neigh.default.gc_thresh1=1024 net.ipv4.neigh.default.gc_thresh2=2048 net.ipv4.neigh.default.gc_thresh3=4096 net.nf_conntrack_max = 262144 Странность еще в том, что tcpdump показывает, что незаначенными из интерфейса выходят только те пакеты, у которых установлен флаг RST: 10:20:22.621074 IP (tos 0x0, ttl 253, id 65259, offset 0, flags [none], proto 6, length: 40) 10.1.1.1.24985 > 195.218.182.35.80: R [tcp sum ok] 719731406:719731406(0) win 32768
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "iptables съел мозг"
	Сообщение от Alexander (??) on 14-Окт-08, 11:50
	>Странность еще в том, что tcpdump показывает, что незаначенными из интерфейса выходят >только те пакеты, у которых установлен флаг RST: >10:20:22.621074 IP (tos 0x0, ttl 253, id 65259, offset 0, flags [none], proto 6, length: 40) 10.1.1.1.24985 > 195.218.182.35.80: R [tcp sum ok] 719731406:719731406(0) win 32768 Сейчас проверил - а других пакетов с этого сорца и нету! Очевидно, вирусятина у клиента. Но это как-то все равно не дает ответа на первоначальный вопрос..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 14-Окт-08, 12:01
	>А не может это быть как-то связано с переполнением внутренних таблиц? Может >эти параметры как-то негативно влияют? да вроде бы, не может. >Странность еще в том, что tcpdump показывает, что незаначенными из интерфейса выходят >только те пакеты, у которых установлен флаг RST: Это уже совсем другой вопрос, почему RST-пакеты не натятся, нужно правила смотреть (видимо вы их и не натите). А если для остальных пакетов трансляция работает, значит второй мой вариант отпадает, и остается только первый. Вообще ничего в лог не попадает, или "почти ничего"? NEW-пакеты (для TCP это чаще всего SYN) проходить это правило, насколько я понимаю, обязаны, а вот остальные TCP-пакеты туда и не попадут, и это правильно. Проверьте на icmp-пакетах - эти должны попадать всегда. А какие опции лога используете, может с ними что не так? И еще, я так понимаю, у вас все, кроме лога на nat, работает правильно?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "iptables съел мозг"
	Сообщение от Alexander (??) on 14-Окт-08, 15:12
	>Это уже совсем другой вопрос, почему RST-пакеты не натятся, нужно правила смотреть >(видимо вы их и не натите). Спец. правил для RST-пакетов у меня нет. >Вообще ничего в лог не попадает, или "почти ничего"? Конкретно для этого клиента - вообще ничего, т.к. кроме пакетов RST он ничего не посылает. >NEW-пакеты (для TCP это чаще всего SYN) проходить это правило, насколько я понимаю, >обязаны, а вот остальные TCP-пакеты туда и не попадут, и это >правильно. Можно вот это место по-подробнее? Почему остальные не должны попадать в nat:POSTROUTING? >Проверьте на icmp-пакетах - эти должны попадать всегда. Проверял на другом клиенте с легитимным трафиком (icmp и tcp/80) - в лог все попадает, как и должно: # iptables -nL -t nat -v --line-numbers|grep LOG 1        4   152 LOG        all  --  *      *       10.4.1.43            0.0.0.0/0           LOG flags 0 level 4 2        0     0 LOG        all  --  *      *       10.4.1.1            0.0.0.0/0           LOG flags 0 level 4 >И еще, я так понимаю, у вас все, кроме лога на nat, работает правильно? Да, все работает правильно. Вот только не понятно, почему RST-пакеты не натятся и в nat:POSTROUTING не попадают..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 14-Окт-08, 18:18
	>Можно вот это место по-подробнее? Почему остальные не должны попадать в nat:POSTROUTING? http://iptables-tutorial.frozentux.net/chunkyhtml/x1237.html Note that, as we have said before, only the first packet in a stream will hit this table. After this, the rest of the packets will automatically have the same action taken on them as the first packet. (Отметим, что как и было сказано выше, только первый пакет потока попадет в эту таблицу. После этого, к остальным пакетам будет автоматически применено то же действие, что и для первого). По этой причине POSTROUTING не рекомендуется использовать для фильтрации. >Да, все работает правильно. Вот только не понятно, почему RST-пакеты не натятся >и в nat:POSTROUTING не попадают.. А вы смотрели tcpdump'ом на внутреннем интерфейсе или на внешнем? Если на внутреннем, то все правильно, но непонятно зачем клиент шлет ни с того ни с сего RST-пакеты (это понятно только если есть попытки соединения извне, но это или dnat, или какой-то хитрый протокол, в любом случае вы бы отловили эти пакеты tcpdump'ом тоже). Ну или клиент сошел с ума. А если на внешнем, то вполне понятно, что вы не видите другие пакеты - ведь они натятся, и вы видите внешний адрес шлюза. Тогда непонятно только, почему не натятся RST-пакеты - ответ на этот вопрос может найтись, если вы приведете часть iptables-save для таблицы nat.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "iptables съел мозг"
	Сообщение от Alexander (??) on 14-Окт-08, 23:13
	>По этой причине POSTROUTING не рекомендуется использовать для фильтрации. Понял. >А вы смотрели tcpdump'ом на внутреннем интерфейсе или на внешнем? Смотрел и там и там. И на обоих сразу: tcpdump -n -vv -i any host 10.4.1.1 Сейчас как раз есть и нормальные пакеты и "рстшные". Вот нормальные: 23:06:51.432284 IP (tos 0x0, ttl 127, id 18902, offset 0, flags [DF], proto 6, length: 48) 10.4.1.1.10459 > 93.186.227.126.80: S [tcp sum ok] 3659876870:3659876870(0) win 32768 <mss 1460,nop,nop,sackOK> 23:06:51.433527 IP (tos 0x0, ttl  57, id 0, offset 0, flags [DF], proto 6, length: 48) 93.186.227.126.80 > 10.4.1.1.10459: S [tcp sum ok] 1161138919:1161138919(0) ack 3659876871 win 5840 <mss 1460,nop,nop,sackOK> 23:06:51.433530 IP (tos 0x0, ttl  57, id 0, offset 0, flags [DF], proto 6, length: 48) 93.186.227.126.80 > 10.4.1.1.10459: S [tcp sum ok] 1161138919:1161138919(0) ack 3659876871 win 5840 <mss 1460,nop,nop,sackOK> Как видно, 1-й пакет - это eth1 -> eth0, 2-й пакет - это internet -> eth0 и 3-й пакет - это eth0 -> eth1. Пакета eth0 -> internet не видим, т.к. он идет уже с другим (наченным) сорцом. А вот "левые": 23:10:21.620912 IP (tos 0x0, ttl 254, id 65259, offset 0, flags [none], proto 6, length: 40) 10.4.1.1.1214 > 66.35.253.228.80: R [tcp sum ok] 840041806:840041806(0) win 4096 23:10:21.620975 IP (tos 0x0, ttl 253, id 65259, offset 0, flags [none], proto 6, length: 40) 10.4.1.1.1214 > 66.35.253.228.80: R [tcp sum ok] 840041806:840041806(0) win 4096 1-й: eth1 -> eth0 2-й: eth0 -> internet, т.е. нат не сработал >Тогда непонятно только, почему не натятся RST-пакеты - ответ на этот >вопрос может найтись, если вы приведете часть iptables-save для таблицы nat. Какую цепочку таблицы nat привести?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 15-Окт-08, 00:09
	>Как видно, 1-й пакет - это eth1 -> eth0, 2-й пакет - это internet -> eth0 и 3-й пакет - это eth0 -> eth1. Пакета eth0 -> internet не видим, т.к. он идет уже с другим (наченным) сорцом. Я не понимаю, что тут происходит, но не совсем то, что вы описываете. internet->eth0 попадают в tcpdump с destination address вашего шлюза, а не локального хоста, отфильтровываются правилом host 10.4.1.1 и не отображаются. Так что пакет 2-3 пойман именно на eth1, а вот почему два раза - не имею представления. >А вот "левые": >23:10:21.620912 IP (tos 0x0, ttl 254, id 65259, offset 0, flags [none], proto 6, length: 40) 10.4.1.1.1214 > 66.35.253.228.80: R [tcp sum ok] 840041806:840041806(0) win 4096 >23:10:21.620975 IP (tos 0x0, ttl 253, id 65259, offset 0, flags [none], proto 6, length: 40) 10.4.1.1.1214 > 66.35.253.228.80: R [tcp sum ok] 840041806:840041806(0) win 4096 > >1-й: eth1 -> eth0 >2-й: eth0 -> internet, т.е. нат не сработал А это, соответственно, ответ клиента - RST-пакет в ответ на пришедший SYN-пакет, пойманный на интерфейсе eth1, но опять отображенный дважды. Предполагаю что он затем успешно "занатен", но мы этого опять же не видим из-за фильтра tcpdump'а. Так что похоже на то, что нат работает, и работает правильно, а вопрос только в том, почему пакеты на eth1 отображаются дважды. Предполагаю, что вы используете vlan или еще как-то хитрите (хотелось бы увидеть вывод ifconfig и ip link). Для проверки моей догадки попробуйте слушать одновременно eth0 и eth1, но в разных сессиях и только их, а не any - думаю, все будет в порядке. Если же все будет не в порядке, а левых интерфейсов нет, тогда все совсем странно, и приведите пожалуйста все цепочки таблицы nat. Vlan бы все объяснил - тогда вы видите один и тот же пакет - тагированный на физическом eth1-интерфейсе и нетагированный на vlan-интерфейсе. Надеюсь, вы их используете, уж очень все сходится)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "iptables съел мозг"
	Сообщение от Alexander (??) on 15-Окт-08, 13:00
	Я не уточнил, сорри. Конфиг такой: eth0 - интерфейс смотрит в интернет eth1.x - клиентские виланы В данном случае, когда я пишу eth1, имеется в виду eth1.442. Т.е. путь пакета такой: клиент -> eth1.442 -> linux -> eth0 -> internet Поэтому, 1-й пакет - это eth1.442->linux. Этот же пакет на eth0 мы не видим, т.к. он занатился и не попал в фильтр tcpdump'а. >internet->eth0 попадают в tcpdump с destination address вашего шлюза, >а не локального хоста, отфильтровываются правилом host 10.4.1.1 и не отображаются. Так >что пакет 2-3 пойман именно на eth1, а вот почему два раза - не имею представления. Нет, пакет 2-3 пойман сначала на eth0, а потом на eth1, поэтому дважды. >А это, соответственно, ответ клиента - RST-пакет в ответ на пришедший SYN-пакет, Никаких син-пакетов нет, т.к. для клиента внешние порты не прокидываются. Т.е. никто из интернета с ним устанавливать соединение не может. Инициатором может выступать только сам клиент. Думаю, путаница возникла именно из-за непонятки за каким интерфейсом сидит клиент: eth0 или eth1. Вроде как теперь все должно стать на свои места. Если по-прежнему нужны выводы ip link/addr и содержимое таблицы нат, сообщите - подумаю, как это лучше сделать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 15-Окт-08, 13:25
	Да нет же, все у вас в порядке и работает правильно. Вланы все объясняют. >Нет, пакет 2-3 пойман сначала на eth0, а потом на eth1, поэтому >дважды. Он не мог быть пойман на eth0, потому что dst-адрес у него при приходе на eth0 - внешний адрес вашего шлюза, а не 10.4.1.1. Это один и тот же пакет, пойманный один раз на eth1, а второй раз на eth1.442. >Никаких син-пакетов нет, т.к. для клиента внешние порты не прокидываются. я конечно имел в виду syn ack - тот самый пакет 2-3. >Если по-прежнему нужны выводы ip link/addr и содержимое таблицы нат, сообщите - >подумаю, как это лучше сделать. Не нужны. У вас все в порядке. Когда вы используете tcpdump -i any, он слушает на всех интерфейсах. В отличие, например, от алиасов, vlan-интерфейсы являются разными интерфейсами, поэтому tcpdump слушает И НА eth1, И НА eth1.442, и следовательно РЕГИСТРИРУЕТ КАЖДЫЙ КЛИЕНТСКИЙ ПАКЕТ ДВАЖДЫ. А пакеты, уходящие с eth0 или приходящие на eth0 вы не видите, потому что nat у вас работает корректно!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "iptables съел мозг"
	Сообщение от Alexander (??) on 15-Окт-08, 15:35
	>Он не мог быть пойман на eth0, потому что dst-адрес у него >при приходе на eth0 - внешний адрес вашего шлюза, а не >10.4.1.1. Это один и тот же пакет, пойманный один раз на >eth1, а второй раз на eth1.442. Точно! Сорри, ступил. >я конечно имел в виду syn ack - тот самый пакет 2-3. Вопросов по 1-й (правильной) пачке пакетов - нет. На то они и правильные :) Смотрите: # tcpdump -n -vv -i eth0 host 10.4.1.1 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:32:13.338613 IP (tos 0x0, ttl 253, id 65259, offset 0, flags [none], proto 6, length: 40) 10.4.1.1.28894 > 195.190.107.38.80: R [tcp sum ok] 3488535878:3488535878(0) win 65535 15:32:13.339493 IP (tos 0x0, ttl 253, id 65259, offset 0, flags [none], proto 6, length: 40) 10.4.1.1.28895 > 195.190.107.38.80: R [tcp sum ok] 3381658086:3381658086(0) win 65535 15:32:13.340910 IP (tos 0x0, ttl 253, id 65259, offset 0, flags [none], proto 6, length: 40) 10.4.1.1.14275 > 74.125.43.127.80: R [tcp sum ok] 48368824:48368824(0) win 32768 Вопрос: откуда на eth0 пакеты с сорцом 10.4.1.1 ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 16-Окт-08, 22:22
	>Вопрос: откуда на eth0 пакеты с сорцом 10.4.1.1 ? Приведите уже ваши сверхсекретные правила для nat :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "iptables съел мозг"
	Сообщение от Alexander (??) on 17-Окт-08, 12:56
	>Приведите уже ваши сверхсекретные правила для nat :) Я все-таки приведу только цепочку POSTROUTING, т.к. в таблице nat только она имеет в данном случае смысл (напомню, что в конце mangle:POSTROUTING пакеты еще присутствуют, а в начале nat:POSTROUTING их уже нет): # iptables -t nat -nL POSTROUTING -v --line-numbers Chain POSTROUTING (policy ACCEPT 927K packets, 89M bytes) num   pkts bytes target     prot opt in     out     source               destination 1        0     0 SNAT       all  --  *      *       xxx.yyy.160.0/24      192.168.19.0/24     to:192.168.19.254 2        0     0 SNAT       all  --  *      *       xxx.yyy.166.248/29    192.168.19.0/24     to:192.168.19.254 3        0     0 SNAT       all  --  *      *       xxx.yyy.160.0/24      192.168.22.48/28    to:192.168.22.62 4        0     0 SNAT       all  --  *      *       xxx.yyy.166.248/29    192.168.22.48/28    to:192.168.22.62 5      672  544K SNAT       all  --  *      *       xxx.yyy.160.0/24      192.168.22.32/28    to:192.168.22.46 6        0     0 SNAT       all  --  *      *       xxx.yyy.166.248/29    192.168.22.32/28    to:192.168.22.46 7        0     0 SNAT       all  --  *      *       xxx.yyy.160.12        172.16.0.0/16       to:172.16.1.1 8        0     0 SNAT       all  --  *      *       0.0.0.0/0            168.219.149.237     to:168.219.149.236 9        0     0 SNAT       all  --  *      *       xxx.yyy.160.13        172.30.0.0/16       to:172.30.0.254 10       0     0 SNAT       all  --  *      *       xxx.yyy.160.12        172.30.0.0/16       to:172.30.0.254 11       0     0 SNAT       all  --  *      *       xxx.yyy.160.13        172.31.254.0/28     to:172.31.254.14 12       0     0 SNAT       all  --  *      *       xxx.yyy.160.12        172.31.254.0/28     to:172.31.254.14 13       0     0 ACCEPT     all  --  *      *       10.21.254.6          xxx.yyy.160.0/20 14       0     0 ACCEPT     all  --  *      *       10.21.254.6          aaa.bbb.112.0/20 15       0     0 SNAT       all  --  *      *       10.21.254.6          0.0.0.0/0           to:aaa.bbb.115.178 16       0     0 ACCEPT     all  --  *      *       192.168.99.252       xxx.yyy.160.0/20 17       0     0 SNAT       all  --  *      *       192.168.99.252       0.0.0.0/0           to:xxx.yyy.166.252 18       0     0 ACCEPT     all  --  *      *       10.21.254.4          xxx.yyy.160.0/20 19       0     0 ACCEPT     all  --  *      *       10.21.254.4          aaa.bbb.112.0/20 20       0     0 SNAT       all  --  *      *       10.21.254.4          0.0.0.0/0           to:aaa.bbb.115.178 21       0     0 ACCEPT     all  --  *      *       10.21.254.3          xxx.yyy.160.0/20 22       0     0 ACCEPT     all  --  *      *       10.21.254.3          aaa.bbb.112.0/20 23       0     0 SNAT       all  --  *      *       10.21.254.3          0.0.0.0/0           to:aaa.bbb.115.178 24       0     0 ACCEPT     all  --  *      *       10.21.254.1          xxx.yyy.160.0/20 25       0     0 ACCEPT     all  --  *      *       10.21.254.1          aaa.bbb.112.0/20 26       0     0 SNAT       all  --  *      *       10.21.254.1          0.0.0.0/0           to:aaa.bbb.115.178 27       0     0 ACCEPT     all  --  *      *       192.168.99.160       xxx.yyy.160.0/20 28       0     0 ACCEPT     all  --  *      *       192.168.99.200       xxx.yyy.160.0/24 29       0     0 SNAT       all  --  *      *       192.168.99.160       0.0.0.0/0           to:xxx.yyy.166.252 30       0     0 ACCEPT     all  --  *      *       192.168.99.164       xxx.yyy.160.0/20 31       0     0 ACCEPT     all  --  *      *       192.168.99.200       xxx.yyy.160.0/24 32       0     0 SNAT       all  --  *      *       192.168.99.164       0.0.0.0/0           to:xxx.yyy.166.252 33       0     0 ACCEPT     all  --  *      *       192.168.99.161       xxx.yyy.160.0/20 34       0     0 ACCEPT     all  --  *      *       192.168.99.200       xxx.yyy.160.0/24 35       0     0 SNAT       all  --  *      *       192.168.99.161       0.0.0.0/0           to:xxx.yyy.166.252 36       0     0 ACCEPT     all  --  *      *       192.168.99.251       xxx.yyy.160.0/20 37       0     0 SNAT       all  --  *      *       192.168.99.251       0.0.0.0/0           to:xxx.yyy.166.252 38       0     0 ACCEPT     all  --  *      *       10.21.254.5          xxx.yyy.160.0/20 39       0     0 ACCEPT     all  --  *      *       10.21.254.5          aaa.bbb.112.0/20 40       0     0 SNAT       all  --  *      *       10.21.254.5          0.0.0.0/0           to:aaa.bbb.115.178 41       0     0 ACCEPT     all  --  *      *       192.168.99.151       xxx.yyy.160.0/20 42       0     0 SNAT       all  --  *      *       192.168.99.151       0.0.0.0/0           to:xxx.yyy.166.252 43       0     0 ACCEPT     all  --  *      *       10.21.254.2          xxx.yyy.160.0/20 44       0     0 ACCEPT     all  --  *      *       10.21.254.2          aaa.bbb.112.0/20 45       0     0 SNAT       all  --  *      *       10.21.254.2          0.0.0.0/0           to:aaa.bbb.115.178 46       0     0 ACCEPT     all  --  *      *       192.168.19.4         xxx.yyy.160.0/20 47       0     0 SNAT       all  --  *      *       192.168.19.4         0.0.0.0/0           to:xxx.yyy.166.252 48       0     0 ACCEPT     all  --  *      *       192.168.99.162       xxx.yyy.160.0/20 49       0     0 ACCEPT     all  --  *      *       192.168.99.200       xxx.yyy.160.0/24 50       0     0 SNAT       all  --  *      *       192.168.99.162       0.0.0.0/0           to:xxx.yyy.166.252 51       0     0 ACCEPT     all  --  *      *       192.168.99.163       xxx.yyy.160.0/20 52       0     0 ACCEPT     all  --  *      *       192.168.99.200       xxx.yyy.160.0/24 53       0     0 SNAT       all  --  *      *       192.168.99.163       0.0.0.0/0           to:xxx.yyy.166.252 54       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.254       MARK match 0x80/0x87 55       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.62        MARK match 0x80/0x87 56       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.62        MARK match 0x80/0x87 57    6902  576K SNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x80/0x87 to:aaa.bbb.115.250 58       7   364 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.254       MARK match 0x82/0x87 59       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.62        MARK match 0x82/0x87 60       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.62        MARK match 0x82/0x87 61    296K   27M SNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x82/0x87 to:aaa.bbb.117.250 62       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.254       MARK match 0x84/0x87 63       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.62        MARK match 0x84/0x87 64       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.20.20.62        MARK match 0x84/0x87 65       0     0 SNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x84/0x87 to:aaa.bbb.115.250
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 19-Окт-08, 04:55
	Судя по приведенным правилам, у вас натятся только маркированные пакеты. Возможно, RST-пакеты по какой-то причине оказываются немаркированными. Приведите правила маркировки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "iptables съел мозг"
	Сообщение от Alexander (??) on 20-Окт-08, 15:05
	Вся маркировка делается в таблице mangle. Оставил только значащие правила. Chain PREROUTING (policy ACCEPT 1228K packets, 1054M bytes) num   pkts bytes target     prot opt in     out     source               destination 2    1228K 1054M LOCAL      all  --  *      *       0.0.0.0/0            0.0.0.0/0 3     871K  739M IMQ        all  --  eth1.+ *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0 762   1689  143K SET_ROUTE_xxx  all  --  *      *       10.4.1.1            0.0.0.0/0 Chain FORWARD (policy ACCEPT 1226K packets, 1054M bytes) num   pkts bytes target     prot opt in     out     source               destination 507   1689  143K ENABLE_PROXY  all  --  *      *       10.4.1.1            0.0.0.0/0 Chain POSTROUTING (policy ACCEPT 1228K packets, 1058M bytes) num   pkts bytes target     prot opt in     out     source               destination 409   1689  143K SET_SNAT   all  --  *      *       10.4.1.1            0.0.0.0/0 Chain ENABLE_PROXY (626 references) num   pkts bytes target     prot opt in     out     source               destination 1    75236   56M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0/0x7 MARK set 0x10 2     179K  139M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2/0x7 MARK set 0x12 3        0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x4/0x7 MARK set 0x14 4     437K  326M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x1/0x7 MARK set 0x11 5        0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x3/0x7 MARK set 0x13 6        0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x5/0x7 MARK set 0x15 7     692K  520M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0 Chain LOCAL (1 references) num   pkts bytes target     prot opt in     out     source               destination <маркируем локальный трафик> 10    616K  659M MARK       all  --  *      *       0.0.0.0/0            10.0.0.0/8          MARK set 0x1 13   1228K 1054M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0 Chain SET_ROUTE_xxx (422 references) num   pkts bytes target     prot opt in     out     source               destination 1     179K  139M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0/0x1 MARK set 0x2 2     563K  427M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0 Chain SET_SNAT (517 references) num   pkts bytes target     prot opt in     out     source               destination 1     1305  130K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0/0x7 MARK set 0x80 2     179K  139M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2/0x7 MARK set 0x82 3        0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x4/0x7 MARK set 0x84 4     590K  428M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0 >Судя по приведенным правилам, у вас натятся только маркированные пакеты Еще раз хочу заострить внимание, что до ната (nat:POSTROUTING) дело не доходит. Уже в 1-м правиле приведенные в предыдущих постах пакеты отсутствуют.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 21-Окт-08, 03:18
	Несколько вопросов: есть ли разница (хоть какая-нибудь) в правилах для хоста 10.4.1.1 и 10.4.1.43? цепочка ENABLE_PROXY и соответствующие марки - где-нибудь используются? используете ли вы прозрачное проксирование? используете ли вы REJECT --reject-with tcp-reset? Это могло бы объяснить возникновение этих непонятно к чему относящихся RST-пакетов, осталось бы только выяснить, что именно при этом reject'ится и почему они не натятся. может быть, было бы понятнее, если бы вы могли привести соседние с RST пакеты из лога tcpdump'а. а так к сожалению нет больше идей
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "iptables съел мозг"
	Сообщение от Alexander (??) on 21-Окт-08, 13:41
	>есть ли разница (хоть какая-нибудь) в правилах для хоста 10.4.1.1 и 10.4.1.43? нет >цепочка ENABLE_PROXY и соответствующие марки - где-нибудь используются? для этого хоста - нет >используете ли вы прозрачное проксирование? да, но не для этого хоста. есть спец. цепочка, где маркируются пакеты, которые потом будут завернуты на прозрачный прокси. пакеты для этого хоста в ту цепочку не направляются. >используете ли вы REJECT --reject-with tcp-reset? да, в одном месте: # iptables-save | grep tcp-reset -A INPUT -d ! aaa.bbb.160.25 -p tcp -m tcp --dport 179 -j REJECT --reject-with tcp-reset >может быть, было бы понятнее, если бы вы могли привести соседние с >RST пакеты из лога tcpdump'а. а других пакетов вообще сейчас нет.. >а так к сожалению нет больше идей жаль :( но все равно спасибо за попытку помочь!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "iptables съел мозг"
	Сообщение от Alexander (??) on 21-Окт-08, 14:24
	сейчас провел эксперимент: на 10.4.1.43 сгенерировал с помощью hping 1 tcp пакет, идентичный по параметрам пакетам с 10.4.1.1: hping 81.19.70.13 -c 1 -V -t 255 -N 65259 -H 6 -s 22653 -p 80 -w 32768 -M 3154278569 -R -d 40 using eth1:1, addr: 10.4.1.43, MTU: 1500 HPING 81.19.70.13 (eth1:1 81.19.70.13): R set, 40 headers + 40 data bytes --- 81.19.70.13 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms и он не занатился: # tcpdump -e -X -s 0 -n -vv -i eth0 host 10.4.1.43 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:19:59.107989 00:15:17:38:d5:22 > 00:30:4f:51:1f:f3, ethertype IPv4 (0x0800), length 94: IP (tos 0x0, ttl 254, id 65259, offset 0, flags [none], proto 6, length: 80) 10.4.1.43.22653 > 81.19.70.13.80: R [tcp sum ok] 3154278569:3154278609(40) win 32768 [RST+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]         0x0000:  4500 0050 feeb 0000 fe06 1b6d 0a04 012b  E..P.......m...+         0x0010:  5113 460d 587d 0050 bc02 78a9 573f d208  Q.F.X}.P..x.W?..         0x0020:  5004 8000 efc0 0000 5858 5858 5858 5858  P.......XXXXXXXX         0x0030:  5858 5858 5858 5858 5858 5858 5858 5858  XXXXXXXXXXXXXXXX         0x0040:  5858 5858 5858 5858 5858 5858 5858 5858  XXXXXXXXXXXXXXXX
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "iptables съел мозг"
	Сообщение от thehangedman (ok) on 22-Окт-08, 00:29
	Так вот значит вы и нашли ответ) Повторил ваш эксперимент и получил тот же результат. Успешно натятся только syn-пакеты, посланные таким образом; любые другие типы пакетов не натятся. А ведь так и должно быть - для них не найдены сессии в conntrack-таблице и значит они не имею состояния ESTABLISHED, значит старая SNAT-сессия к ним не применится; а так как они не являются правильными NEW или RELATED пакетами, то и новую сессию не начинают, и поэтому новую SNAT-сессию тоже не начнут. Вместо NEW они получают состояние INVALID, и их можно просто дропать в таблице filter по -m state --state INVALID. А мы все это время слишком глубоко копали. Один из сопутствующих параметров sysctl - net.ipv4.netfilter.ip_conntrack_tcp_be_liberal: when enabled, only out of window reset (RST) segments are marked as INVALID; when disabled (default), all out of window packets are marked as INVALID. А уж почему клиент шлет RST-пакеты для уже закрытых соединений - другой вопрос, в данном случае не важный и не интересный)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "iptables съел мозг"
	Сообщение от Alexander (??) on 22-Окт-08, 12:21
	>Повторил ваш эксперимент и получил тот же результат. Успешно натятся только syn-пакеты, >посланные таким образом; любые другие типы пакетов не натятся. А ведь >так и должно быть - для них не найдены сессии в Да, логика подсказывает, что так и должно быть. Странно, что в руководствах такая ситуация не описана.. >поэтому новую SNAT-сессию тоже не начнут. Вместо NEW они получают состояние >INVALID, и их можно просто дропать в таблице filter по -m state --state INVALID. Да, как только вчера стало понятно, что единичные пакеты так же дропаются, допер до статуса INVALID :) >А уж почему клиент шлет RST-пакеты для уже закрытых соединений - другой >вопрос, в данном случае не важный и не интересный) Да, вирус скорее всего.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]