Jump to content
Калькуляторы

"ipfw pipe tablearg ip" блокирует icmp-пакеты

Есть 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?

Edited by Ilya Evseev

Share this post


Link to post
Share on other sites

Есть ipfw на шлюзе под управлением FreeBSD 8.2:

Что посоветует всезнающий ALL?

 

покажите uname -a

Share this post


Link to post
Share on other sites

Есть 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

Share this post


Link to post
Share on other sites

(по крайней мере, раньше "icmp" у ipfw не считался частью "ip").

Вы что-то путаете

 

Что посоветует всезнающий ALL?

 

ipfw pipe show, на тему mask src-port|dst-port|proto

Share this post


Link to post
Share on other sites

ipfw pipe show, на тему mask src-port|dst-port|proto

Пока передаётся icmp, там пусто.

Когда идёт TCP, там появляется IP в нужных пайпах.

 

P.S. Если бы пакет заходил в правило ipfw, то у правила росли бы счётчики байтов-пакетов,

но при пинге в счётчиках нули, то есть ICMP в правило не заходит вообще и к dummynet'у не попадает.

Share this post


Link to post
Share on other sites

Что очень странно. Может, 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

Share this post


Link to post
Share on other sites

А сам pipe #1 в природе существует?

one_pass включен? Иначе пакет пойдёт дальше.

Share this post


Link to post
Share on other sites

one_pass включен? Иначе пакет пойдёт дальше.

one_pass выключен, т.к. из ipfw вызывается netgraph.

tcp/udp-пакеты заходят в pipe-правило, выходят из него и идут дальше.

icmp не заходят (и не должны), а блокируются (хотя должны просто пройти на следующее правило).

 

сам pipe #1 в природе существует?

Существует и в нём нормально возникает динамический pipe, когда идёт tcp/udp-трафик.

Edited by Ilya Evseev

Share this post


Link to post
Share on other sites

icmp не заходят (и не должны), а блокируются (хотя должны просто пройти на следующее правило).

При указании "any" - должны, а "ip" - синоним "any", как же иначе?

Это и по логу видно.

Share this post


Link to post
Share on other sites

При указании "any" - должны, а "ip" - синоним "any", как же иначе?

Это и по логу видно.

Я, собственно, этот лог и привел, чтобы показать, что должны, и у меня "заходят".

 

Как у Ильи они не попадают, я не понимаю. И как вообще icmp может быть не ip?

Edited by littlesavage

Share this post


Link to post
Share on other sites

Если написать

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

Share this post


Link to post
Share on other sites

Ну что за каша!

 

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 пакетах.

 

 

Share this post


Link to post
Share on other sites

Подозреваю, что затык всё же в PF. Что будет, если его отключить?

Share this post


Link to post
Share on other sites

Всё чудесатее и чудесатее.

Оказывается, проблема не только с 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

 

Куда ещё смотреть?

Edited by Ilya Evseev

Share this post


Link to post
Share on other sites

Всё чудесатее и чудесатее.

Оказывается, проблема не только с ICMP, но и с UDP.

 

Куда ещё смотреть?

 

обновите до STABLE

Share this post


Link to post
Share on other sites

А попробуйте IPFW (с думминетом) в ядро добавить, а не модулем... и судя по наличию ALTQ и device pf тоже. Ибо на пачке машин в разных конфигурациях все это более чем активно юзается и работает. Никаких выпадений никаких протоколов не обнаружено. Но у меня везде ipfw и pf, если используются, то они есть в ядре (что используется, если что то одно, то одно, если оба, то оба). хз, может там и что намудрили с вариантом загружено модулем. Там еще и порядок загрузки играть рояль может.

 

В pf вы никаких там маркировок хитрых не делаете ? А то может оно после навески тегов каких дуреет ?

Share this post


Link to post
Share on other sites

ALTQ - нет в модулях.

 

Разницу между модулем и в ядре не замечал. Модулем - удобнее отлаживать модуль.

 

 

Share this post


Link to post
Share on other sites

ну в приведенном выше конфиге других принципиальных отличий от того, что у меня работает я не вижу.. И, по моему, мы модуль, типа, не отлаживаем ? В общем, я бы все добавил в ядро и потом смотрел. А то ipfw в ядре, а думминет - нет. ХЗ, может там что и глючит. И, если поможет, то send-pr бы неплохо бы сделать.

Share this post


Link to post
Share on other sites

А я вот подумал, может, это ng_netflow подгаживает? Вспомнил, что был как-то с ним баг, что после подгрузки и создания ноды переставали ходить traceroute'ы с самого сервера.

Share this post


Link to post
Share on other sites

Перед send-pr не плохо бы обновить исходники и обновить из них систему полностью, без выкрутасов в make.conf типа o3 и пр, может и само пройдёт.

 

PS: мы - да :)

http://www.freebsd.o...r=161908#reply1

 

 

 

PPS: гадость которая может точно вылезти при подгрузке модулем: модуль и ядро могут быть собраны из исходников разных версий, соответственно могут различаться структуры, смещения и тп, и вылазить будет странное даже в дебагере.

 

 

 

Share this post


Link to post
Share on other sites

А я вот подумал, может, это ng_netflow подгаживает? Вспомнил, что был как-то с ним баг, что после подгрузки и создания ноды переставали ходить traceroute'ы с самого сервера.

Год назад с ним была неприятность - перестал пропускать пакеты, как сейчас dummynet.

Вылечилось заменой "ipfw netgraph" на "ipfw ngtee".

 

Проблему с dummynet сейчас удалось обойти, поменяв "in" на "out", т.е. переместив входящий шейпер с WAN- на LAN-интерфейс.

Исходящий нормально работает и там, и там.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this