sirmax Posted December 24, 2014 · Report post Коллеги, не выходит заставить работать коннлимит внутри неймспейса .. Ядро Linux node-1.domain.tld 2.6.32-431.el6.x86_64 #1 SMP Wed May 14 15:10:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux modinfo xt_connlimit filename: /lib/modules/2.6.32-431.el6.x86_64/kernel/net/netfilter/xt_connlimit.ko alias: ip6t_connlimit alias: ipt_connlimit license: GPL description: Xtables: Number of connections matching author: Jan Engelhardt <jengelh@medozas.de> srcversion: 05DDD107AD26EAD1D3A3E86 depends: nf_conntrack vermagic: 2.6.32-431.el6.x86_64 SMP mod_unload modversions ЗЫ Вообще-то это опенстек. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted December 24, 2014 · Report post А что происходит? Точнее, что НЕ происходит? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted December 24, 2014 · Report post Так, создаю 2 неймспейса для чистоты эксперемнта. ns2 имитирует ВМку, ns1 - транзитный /sbin/ip netns add ns1 /sbin/ip netns add ns2 /sbin/ip link add dev local_to_ns1 type veth peer name ns1_to_local /sbin/ip link add dev ns1_to_ns2 type veth peer name ns2_to_ns1 /sbin/ip link set ns1_to_local netns ns1 /sbin/ip link set ns1_to_ns2 netns ns1 /sbin/ip link set ns2_to_ns1 netns ns2 /sbin/ip addr add 172.18.0.1/30 dev local_to_ns1 /sbin/ip link set up dev local_to_ns1 /sbin/ip netns exec ns1 /sbin/ip link set up dev ns1_to_local /sbin/ip netns exec ns1 /sbin/ip link set up dev ns1_to_ns2 /sbin/ip netns exec ns1 /sbin/ip addr add 172.18.0.2/30 dev ns1_to_local /sbin/ip netns exec ns1 /sbin/ip addr add 172.18.0.5/30 dev ns1_to_ns2 /sbin/ip netns exec ns1 /sbin/ip route add 0.0.0.0/0 via 172.18.0.1 /sbin/ip netns exec ns2 /sbin/ip addr add 172.18.0.6/30 dev ns2_to_ns1 /sbin/ip netns exec ns2 /sbin/ip route add 0.0.0.0/0 via 172.18.0.5 /sbin/ip netns exec ns2 /sbin/ip link set up dev ns2_to_ns1 После чего в ns1 (транзитный) добавляю 2 правила нат и connlimit (ine alias ip netns exec ) ine ns1 iptables -t nat -nL Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 172.18.0.6 0.0.0.0/0 to:172.18.0.2 Chain OUTPUT (policy ACCEPT) target prot opt source destination ine ns1 iptables -nL -xv Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 173 packets, 11463 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 #conn/32 > 1 reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination После чего пробую 2 и более раз одновременно ine ns2 telnet mail 25 И - успешно проходят (срабатывания правила нет) ОДНАКО если НАТ вынести из неймспейса в global то правило начинает срабатывать. Потому очевидно вопрос - как заставить работать коннлимит и нат одновременно - дело похоже не в неймспейсах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted December 24, 2014 · Report post все страньше и страньше - на тестовом окружении с убунтой - не воспроизводится (т.е. работает как ожидалось) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted December 24, 2014 (edited) · Report post Ага, про нат это точно. Насколько я могу покапаться в моих угасающих знаниях, connlimit смотрит в табличку, которую составляет conntrack. Но вся грусть заключается в том, что conntrack собирает информацию _до_ NAT'а. В рузультате коннекшн после НАТа, не зарегистрированный в conntrack каждый раз считается первым. :( Что делать? А фиг его знает. Сделать дополнительный ns stack для ната отдельно (попахивает изысканным извращением). У меня НАТ вообще вынесен в пограничный роутер. PS Проверять еще удобно апачевским бенчмарком - ab. Edited December 24, 2014 by vop Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted December 24, 2014 · Report post На убунте ip netns exec ns1 conntrack -L | wc -l conntrack v1.4.1 (conntrack-tools): 2 flow entries have been shown. 2 На CentOS ip netns exec ns1 conntrack -L | wc -l conntrack v0.9.13 (conntrack-tools): Operation failed: Connection refused 0 У кого есть проверить ядрышко? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted December 24, 2014 · Report post У кого есть проверить ядрышко? Вопрос не понятен Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted December 24, 2014 · Report post У кого есть проверить ядрышко? Вопрос не понятен Если не затруднилит проверить это только у меня так или еще у кого то. Но ядро нужно от опенстека (Rdo) c поддержкой неймспейсов Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted December 26, 2014 · Report post Дело в ядре - на более новых (попробовал 3.10) - проблемы нет и фильтрация работает как ожидалось. Центос достаточно консервативен. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
BETEPAH Posted December 26, 2014 · Report post Так первым делом надо ELRepo ставить и обновляться. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted December 26, 2014 · Report post Так первым делом надо ELRepo ставить и обновляться. Это не всегда возможно. Я предпочитаю обновляться на ELRepo только если не работает что-то конкретно (как сейчас), все таки шанс поймать баг значительно ниже в стандартных ядрах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...