Разные возможности iptables в VE.i386 на нодах i386 и X86_64
Добрый день! Только обрадовались, что удалось обойти kernel Oops на x86_64, обнаружилось, что внутри VE.i386 iptables почти ничего не умеет. Для сравнения запскали одну и туже VE на нодах с разной архитектурой. Вопрос: Будет ли работать CONNMARK/MARK Target/Match в VE.i386 на X86_64 ноде? Что для этого нужно сделать? Везде использовалось ядро EL5.045 [root@c2d-x8664 conf]# shorewall show capabilities |grep "Not available" Ipset Match: Not available IPP2P Match: Not available Repeat match: Not available [root@devlab-i386 conf]# shorewall show capabilities |grep "Not available" Ipset Match: Not available IPP2P Match: Not available Repeat match: Not available [root@devlab-i386 conf]# vzctl exec 1052 shorewall show capabilities |grep "Not available" Ipset Match: Not available Raw Table: Not available IPP2P Match: Not available Repeat match: Not available [root@c2d-x8664 /]# vzctl exec 1052 shorewall show capabilities |grep "Not available" Connection Tracking Match: Not available Recent Match: Not available Ipset Match: Not available CONNMARK Target: Not available Connmark Match: Not available Raw Table: Not available IPP2P Match: Not available Repeat match: Not available MARK Target: Not available Hashlimit Match: Not available
Re: Разные возможности iptables в VE.i386 на нодах i386 и X86_64
День добрый! Насколько я понимаю, возможности iptables не должны зависеть от архитектур ядра и VE-шки. Скорее всего, на ноде c2d-x8664 какие-то модули iptables были загружены _после_ старта VE #1052 или в /etc/vz/vz.conf в переменной IPTABLES не были перечислены какие-то модули. Попробуйте добавить в IPTABLES все нужные модули (из возможных, man vzctl, search iptables), и попробуйте сравнить снова.
Только что перепроверил еще раз. [root@c2d /]# lsmod |grep ip iptable_raw 2944 0 ipt_ULOG 10376 0 ipt_TTL 3200 0 ipt_ttl 2688 0 ipt_TOS 3072 0 ipt_tos 2432 0 ipt_TCPMSS 5248 0 ipt_SAME 3200 0 ipt_REJECT 6656 4 ipt_REDIRECT 2816 0 ipt_owner 2816 0 ipt_NETMAP 2816 0 ipt_MASQUERADE 3328 0 ipt_LOG 7808 3 ipt_iprange 2688 0 ipt_ECN 3840 0 ipt_ecn 3072 0 ipt_DSCP 3072 0 ipt_dscp 2560 0 ipt_CLUSTERIP 9736 0 ipt_ah 2688 0 ipt_addrtype 2688 4 ip_nat_tftp 2688 0 ip_nat_snmp_basic 11268 0 ip_nat_sip 5120 0 ip_nat_pptp 7172 0 ip_nat_irc 4224 0 ip_nat_h323 8576 0 ip_nat_ftp 4992 0 ip_nat_amanda 3200 0 ip_conntrack_tftp 5720 1 ip_nat_tftp ip_conntrack_sip 9552 1 ip_nat_sip ip_conntrack_pptp 13600 1 ip_nat_pptp ip_conntrack_netbios_ns 3840 0 ip_conntrack_irc 9040 2 ip_conntrack_h323 56256 1 ip_nat_h323 ip_conntrack_ftp 10192 2 ip_conntrack_amanda 6152 1 ip_nat_amanda xt_multiport 4224 4 iptable_nat 10884 2 ip_nat 21392 13 vzrst,ipt_SAME,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ip_nat _tftp,ip_nat_sip,ip_nat_pptp,ip_nat_irc,ip_nat_h323,ip_nat_f tp,ip_nat_amanda,iptable_nat ip_conntrack 68756 26 vzrst,vzcpt,ip_nat_tftp,ip_nat_snmp_basic,ip_nat_sip,ip_nat_ pptp,ip_nat_irc,ip_nat_h323,ip_nat_ftp,ip_nat_amanda,ip_conn track_tftp,ip_conntrack_sip,ip_conntrack_pptp,ip_conntrack_n etbios_ns,ip_conntrack_irc,ip_conntrack_h323,ip_conntrack_ft p,ip_conntrack_amanda,xt_helper,xt_conntrack,xt_CONNMARK,xt_ connmark,xt_state,iptable_nat,ip_nat iptable_mangle 5760 2 nfnetlink 8264 2 ip_nat,ip_conntrack iptable_filter 5632 2 ip_tables 22664 4 iptable_raw,iptable_nat,iptable_mangle,iptable_filter x_tables 20488 43 xt_comment,xt_policy,ipt_ULOG,ipt_TTL,ipt_ttl,ipt_TOS,ipt_to s,ipt_TCPMSS,ipt_SAME,ipt_REJECT,ipt_REDIRECT,ipt_owner,ipt_ NETMAP,ipt_MASQUERADE,ipt_LOG,ipt_iprange,ipt_ECN,ipt_ecn,ip t_DSCP,ipt_dscp,ipt_CLUSTERIP,ipt_ah,ipt_addrtype,xt_tcpmss, xt_pkttype,xt_physdev,xt_NFQUEUE,xt_multiport,xt_MARK,xt_mar k,xt_mac,xt_limit,xt_length,xt_helper,xt_dccp,xt_conntrack,x t_CONNMARK,xt_connmark,xt_CLASSIFY,xt_tcpudp,xt_state,iptabl e_nat,ip_tables [root@c2d /]# vzctl restart 1052 Restarting VE Stopping VE ... VE was stopped VE is unmounted Starting VE ... Mount for 1052 done. VE is mounted Adding IP address(es): 192.168.0.34 Setting CPU units: 1000 Configure meminfo: 2147483647 Set hostname: ipt32dbg VE start in progress... [root@c2d /]# shorewall show capabilities |grep "Not available" Recent Match: Not available Ipset Match: Not available IPP2P Match: Not available Repeat match: Not available Hashlimit Match: Not available [root@c2d /]# vzctl exec 1052 shorewall show capabilities |grep "Not available" Connection Tracking Match: Not available Recent Match: Not available Ipset Match: Not available CONNMARK Target: Not available Connmark Match: Not available Raw Table: Not available IPP2P Match: Not available Repeat match: Not available MARK Target: Not available Hashlimit Match: Not available В 1052.conf IPTABLES="iptable_filter iptable_mangle ipt_limit ipt_multiport ipt_tos ipt_TOS ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_LOG ipt_length ip_conntrack ip_conntrack_ftp ip_conntrack_irc ipt_conntrack ipt_state ipt_helper iptable_nat ip_nat_ftp ip_nat_irc ipt_REDIRECT " PS. Когда проверял на i386 и x86_64 1052.conf был одним и темже.
CONNMARK/MARK используют в интерфейсе переменные типа long, который как известно имеет разный размер на 32-bit и 64-bit архитектурах. Другими словами, для работы этих модулей в 32-bit envinronment на 64-bit ядре требуется в iptables модули дописать compat -- перекодировщик 32-bit userspace формата в 64-bit формат, который использует ядро. При внимательном изучении мы нашли еще несколько модулей, которым требуется compat, но тем не менее IMHO Вы слегка погорячились утверждая что внутри VE.i386 iptables почти ничего не умеет: несколько модулей из ~30 -- это не так уж и много.
В любом случае, спасибо за то, что привлекли наше внимание к этой проблеме. Compats мы вскоре допишем и включим в ядро
Добрый вечер! в продолженье ... Может несколько погорячился, просто пришлось много сделать чтобы добраться до этапа когда стало возможным использовать CONNMARK/ULOG. У тут опять грабли. Основная цель, учет tcp трафика по пользователям. Маркировка connmark/owner затем регистрация в ULOG. Может я зря упираюсь?
Если цель в результате достигните, значит, не зря упирались. А CONNMARK мы сделаем.
В отличие от всего остального linux community для нас неработающий 32-bit iptables compat -- очень серьезная проблема. В отличие от всех остальных у нас его активно юзают А когда когда он не работает -- это не просто отсутвующая функциональность, но и потенциаьлная угроза стабильности системы: без компата и память может покарраптиться, и ядро может упасть. Надеюсь, что мы допилим все compat уже на следующей неделе. С уваженеим, Василий Аверин
Снимаю шляпу, команда отлично поработала! CONNMARK заработал. Трафик классифицирован, теперь есть что считать, но считать нечем. В смысле нет ULOG. На i386 ноде даже без указания в файле конфигурации ULOG работал (при загруженном модуле на ноде). Если ULOG должен работать плз, просто напишите. Буду разбираться. PS. Проверялось на el5 028stab047 ядре + git_diff_028stab049, патч наложился не совсем гладко, "вредные" куски выброшены
Посмотрите в баге 701 два патча http://bugzilla.openvz.org/show_bug.cgi?id=701 они почему-то в 49-е ядро не попали
Это просто сказка какая-то, все что нужно сделано! На тестовой машине даже заработало, только при загрузке модуля ipt_ULOG говорит нечеловеческим голосом: # modprobe ipt_ULOG FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.18-8.1.15.el5.028stab049.1sa2/kernel/net/i pv4/netfilter/ipt_ULOG.ko): Invalid argument Однако обходится # echo "options ipt_ULOG nflog=0" >>/etc/modprobe.conf
C ULOG что-то не то. Коллектор ulog-acctd-0.4.3 вываливает Segmentation fault по причине неправильного(очень большого) размера пакета. В process.c void register_packet(struct iphdr *tmp_iphdr, size_t packet_length, char indev_name[], char outdev_name[], char prefix[], unsigned char mac_len, unsigned char mac[]) { ... unsigned char logbuf[packet_length * 3]; ... При падении packet_length = 1797273648 Хотя возможно корень зла в capture.c /* Go on to next header */ last_nlmsghdr=current_nlmsghdr; current_nlmsghdr=NLMSG_NEXT(current_nlmsghdr, remaining_length); Первый хедер нормально парсится,а на втором сегфолт. Похоже, что неправильно вычисляется смещение или длина пакета.
Мы тоже это заметили http://bugzilla.openvz.org/show_bug.cgi?id=724 netlink в данном случае использует non-compat структуры. К сожалению это просто пофиксить уже не получится. В качестве грубого хака могу предложить переопределить в struct ulog_packet_msg все long на int: unsigned long mark; long timestamp_sec; long timestamp_usec; size_t == long, его размер тоже меняется, так что не забудьте и его тоже на int заменить. size_t data_len; После этого 64-bit ядро будет создавать структуру которую ожидает 32-bit userspace. Но в этом случае будут проблемы на host node: там 64-bit userspace будет ждать 64-bit структуру. А мы будем думать, как это пофиксить нормальным образом С уважением, Василий Аверин
FYI: Patrick McHardy говорит что ipt_ULOG incompatibility исправлена в userspace: ulogd SVN revision r6688. Кроме того, он говорит, что ipt_ULOG obsoleted и заменяется nfnetlink_log (libnetfilter_log, ulogd v2) С уважением, Василий Аверин
Спасибо, попробую применить/мигрировать на nfnetlink_log.