Ilya Evseev Опубликовано 20 октября, 2011 (изменено) · Жалоба Есть ipfw на шлюзе под управлением FreeBSD 8.2: 00100 pipe tablearg ip from any to table(1) in via em0 00200 pipe tablearg ip from table(2) to any out via em0 em0 - внешний интерфейс, NAT делает pf. TCP-трафик через него проходит нормально и шейпируется. ICMP блокируется, хотя он вообще не подходит под условия правил (по крайней мере, раньше "icmp" у ipfw не считался частью "ip"). Ставлю "99 skipto 101 icmp from any to any in via em0" - клиентские пинги начинают ходить. Убираю - прекращают. Что посоветует всезнающий ALL? Изменено 20 октября, 2011 пользователем Ilya Evseev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 20 октября, 2011 · Жалоба Есть ipfw на шлюзе под управлением FreeBSD 8.2: Что посоветует всезнающий ALL? покажите uname -a Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 20 октября, 2011 · Жалоба Есть ipfw на шлюзе под управлением FreeBSD 8.2: Что посоветует всезнающий ALL? покажите uname -a FreeBSD gate.oblnet.ru 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #0: Mon Sep 12 06:02:38 UTC 2011 root@gate.oblnet.ru:/usr/obj/usr/src/sys/GATE i386 Отличия в конфиге ядра от GENERIC: - Убраны строки - cpu I486_CPU cpu I586_CPU makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols - Добавлены - options ALTQ options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 20 октября, 2011 · Жалоба (по крайней мере, раньше "icmp" у ipfw не считался частью "ip"). Вы что-то путаете Что посоветует всезнающий ALL? ipfw pipe show, на тему mask src-port|dst-port|proto Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 21 октября, 2011 · Жалоба ipfw pipe show, на тему mask src-port|dst-port|proto Пока передаётся icmp, там пусто. Когда идёт TCP, там появляется IP в нужных пайпах. P.S. Если бы пакет заходил в правило ipfw, то у правила росли бы счётчики байтов-пакетов, но при пинге в счётчиках нули, то есть ICMP в правило не заходит вообще и к dummynet'у не попадает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 21 октября, 2011 · Жалоба Что очень странно. Может, icmp в pf как-то иначе завернут? > ipfw add 20 pipe 1 log ip from any to 77.88.21.3 out via em0 > ping 77.88.21.3 PING 77.88.21.3 (77.88.21.3): 56 data bytes ping: sendto: Permission denied ping: sendto: Permission denied > # ipfw show 20 00020 8 672 pipe 1 log ip from any to 77.88.21.3 out via em0 > tail -f /var/log/security Oct 21 17:48:03 ls kernel: ipfw: 20 Pipe 1 ICMP:8.0 192.168.254.211 77.88.21.3 out via em0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 21 октября, 2011 · Жалоба А сам pipe #1 в природе существует? one_pass включен? Иначе пакет пойдёт дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 21 октября, 2011 (изменено) · Жалоба one_pass включен? Иначе пакет пойдёт дальше. one_pass выключен, т.к. из ipfw вызывается netgraph. tcp/udp-пакеты заходят в pipe-правило, выходят из него и идут дальше. icmp не заходят (и не должны), а блокируются (хотя должны просто пройти на следующее правило). сам pipe #1 в природе существует? Существует и в нём нормально возникает динамический pipe, когда идёт tcp/udp-трафик. Изменено 21 октября, 2011 пользователем Ilya Evseev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 21 октября, 2011 · Жалоба icmp не заходят (и не должны), а блокируются (хотя должны просто пройти на следующее правило). При указании "any" - должны, а "ip" - синоним "any", как же иначе? Это и по логу видно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 21 октября, 2011 (изменено) · Жалоба При указании "any" - должны, а "ip" - синоним "any", как же иначе? Это и по логу видно. Я, собственно, этот лог и привел, чтобы показать, что должны, и у меня "заходят". Как у Ильи они не попадают, я не понимаю. И как вообще icmp может быть не ip? Изменено 21 октября, 2011 пользователем littlesavage Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 21 октября, 2011 · Жалоба Если написать ipfw pass ip from any to any 80 то icmp естественно не попадет, а попадет только udp или tcp, ибо только там есть порт.. наверное именно отсюда возникла мулька, что под ip попадает только udp/tcp Если же написать ipfw pass ip from any to any то попадает и tcp и udp и icmp и прочие gre Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 октября, 2011 · Жалоба Ну что за каша! L2: ethernet (эзернет) - MacSrc, MacDst, EthernetType= число, указывающее размер/чаще типсодержимого пакета, может указывать IP, ARP, IPv6, VLAN, PPPoE, X25, IPX, APPLETALK, MPLS, NETBEUI, FLOWCONTROL (это который в свичах и сетевухах вкл/выкл), и много другого. L3: любое из выше приведённого в EthernetType, в данном контексте IPv4 и IPv6 - IPSrc, IPDst, IPProto и ещё пачка полей. IPProto может быть tcp, udp, gre, igmp, icmp, icmpv6 и тоже куча всего. L4: любое из выше приведённого в IPProto, в данном контексте tcp, udp- PortSrc, PortDst; gre - номер сессии, icmp - код сообщений. Из названия IpFW видно что речь только про IP, потом уже ему IPv6 добавили, и вроде он немного L2 умеет. И отсюда же следует что VLAN, PPPoE и ARP (который используется для IPv4 исключительно, хотя может намного больше) идут мимо ipfw, а icmp, не может идти мимо, потому что живёт исключительно в IP пакетах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 22 октября, 2011 · Жалоба Подозреваю, что затык всё же в PF. Что будет, если его отключить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 24 октября, 2011 (изменено) · Жалоба Всё чудесатее и чудесатее. Оказывается, проблема не только с ICMP, но и с UDP. Делаю самый простой тест: gate# ipfw show 3 4 5 00003 0 0 count udp from any to 10.11.15.20 in 00004 0 0 pipe 123 udp from any to 10.11.15.20 in 00005 0 0 count udp from any to 10.11.15.20 in gate# ipfw pipe 123 list 00123: 1.000 Mbit/s 0 ms burst 0 q131195 50 sl. 0 flows (1 buckets) sched 65659 weight 0 lmax 0 pri 0 droptail sched 65659 type FIFO flags 0x0 0 buckets 0 active После этого на клиентской машине 10.11.15.20 выполняю "nslookup ya.ru 8.8.8.8". Команда завершается с ошибкой по таймауту. Проверяю счётчики в правилах и пайпе: # ipfw show 3 4 5 00003 3 411 count udp from any to 10.11.15.20 in 00004 3 411 pipe 123 udp from any to 10.11.15.20 in 00005 0 0 count udp from any to 10.11.15.20 in # ipfw pipe 123 list 00123: 1.000 Mbit/s 0 ms burst 0 q131195 50 sl. 0 flows (1 buckets) sched 65659 weight 0 lmax 0 pri 0 droptail sched 65659 type FIFO flags 0x0 0 buckets 1 active 0 ip 0.0.0.0/0 0.0.0.0/0 3 411 0 0 0 Версия системы на шлюзе: FreeBSD 8.2. До этого такой же эффект наблюдался на одном шлюзе с 7.1, но разобраться не удалось. Конфигурация ядра: - убраны строки cpu I486_CPU cpu I586_CPU makeoptions DEBUG=-g - добавлены options ALTQ options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT # kldstat Id Refs Address Size Name 1 33 0xc0400000 c16ab8 kernel 2 1 0xc1017000 59cc ng_netflow.ko 3 6 0xc101d000 d934 netgraph.ko 4 1 0xc102b000 3cd4 ichwd.ko 5 1 0xc102f000 27cc ng_ipfw.ko 6 1 0xc6e64000 e000 dummynet.ko 7 1 0xc6f12000 4000 ng_nat.ko 8 1 0xc6f16000 d000 libalias.ko 9 1 0xc6fa7000 4000 ng_socket.ko 10 1 0xc7363000 5000 ng_ksocket.ko 11 1 0xc7384000 36000 pf.ko 12 1 0xc7596000 2000 blank_saver.ko 13 1 0xcf552000 5000 nullfs.ko /boot/loader.conf ichwd_load="YES" netgraph_load="YES" dummynet_load="YES" ng_ipfw_load="YES" ng_netflow_load="YES" kern.coredump=0 kern.hz=4000 hw.em.rxd=4096 hw.em.txd=4096 hw.em.enable_msi=1 hw.em.rx_int_delay=600 hw.em.tx_int_delay=600 hw.em.rx_abs_int_delay=1000 hw.em.tx_abs_int_delay=1000 /etc/sysctl.conf: kern.ipc.somaxconn=512 net.inet.ip.fw.verbose=1 net.link.ether.inet.log_arp_wrong_iface=0 net.inet.ip.dummynet.io_fast=1 # менял, не помогает net.inet.ip.dummynet.expire=0 # менял, не помогает net.inet.ip.fastforwarding=0 net.inet.ip.redirect=0 net.inet.ip.fw.one_pass=0 net.inet.ip.fw.dyn_buckets=2048 # default=256 net.inet.ip.dummynet.hash_size=512 # default=64 # Drop SYN without RST on closed ports net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 dev.em.0.rx_int_delay=600 dev.em.0.tx_int_delay=600 dev.em.0.rx_abs_int_delay=1000 dev.em.0.tx_abs_int_delay=1000 dev.em.0.rx_processing_limit=1024 Куда ещё смотреть? Изменено 24 октября, 2011 пользователем Ilya Evseev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 24 октября, 2011 · Жалоба Всё чудесатее и чудесатее. Оказывается, проблема не только с ICMP, но и с UDP. Куда ещё смотреть? обновите до STABLE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 25 октября, 2011 · Жалоба А попробуйте IPFW (с думминетом) в ядро добавить, а не модулем... и судя по наличию ALTQ и device pf тоже. Ибо на пачке машин в разных конфигурациях все это более чем активно юзается и работает. Никаких выпадений никаких протоколов не обнаружено. Но у меня везде ipfw и pf, если используются, то они есть в ядре (что используется, если что то одно, то одно, если оба, то оба). хз, может там и что намудрили с вариантом загружено модулем. Там еще и порядок загрузки играть рояль может. В pf вы никаких там маркировок хитрых не делаете ? А то может оно после навески тегов каких дуреет ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 25 октября, 2011 · Жалоба ALTQ - нет в модулях. Разницу между модулем и в ядре не замечал. Модулем - удобнее отлаживать модуль. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 25 октября, 2011 · Жалоба ну в приведенном выше конфиге других принципиальных отличий от того, что у меня работает я не вижу.. И, по моему, мы модуль, типа, не отлаживаем ? В общем, я бы все добавил в ядро и потом смотрел. А то ipfw в ядре, а думминет - нет. ХЗ, может там что и глючит. И, если поможет, то send-pr бы неплохо бы сделать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 25 октября, 2011 · Жалоба А я вот подумал, может, это ng_netflow подгаживает? Вспомнил, что был как-то с ним баг, что после подгрузки и создания ноды переставали ходить traceroute'ы с самого сервера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 25 октября, 2011 · Жалоба Перед send-pr не плохо бы обновить исходники и обновить из них систему полностью, без выкрутасов в make.conf типа o3 и пр, может и само пройдёт. PS: мы - да :) http://www.freebsd.o...r=161908#reply1 PPS: гадость которая может точно вылезти при подгрузке модулем: модуль и ядро могут быть собраны из исходников разных версий, соответственно могут различаться структуры, смещения и тп, и вылазить будет странное даже в дебагере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 25 октября, 2011 · Жалоба А я вот подумал, может, это ng_netflow подгаживает? Вспомнил, что был как-то с ним баг, что после подгрузки и создания ноды переставали ходить traceroute'ы с самого сервера. Год назад с ним была неприятность - перестал пропускать пакеты, как сейчас dummynet. Вылечилось заменой "ipfw netgraph" на "ipfw ngtee". Проблему с dummynet сейчас удалось обойти, поменяв "in" на "out", т.е. переместив входящий шейпер с WAN- на LAN-интерфейс. Исходящий нормально работает и там, и там. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...