Здравствуйте!Столкнулся с ненормальным поведением ipfw.
На машине [FreeBSD 11.0-STABLE] стоит isc-dhcpd. Машина используется для различных тестов. В частности сейчас мне нужно внедрить netgraph в исходящее правило, а оно не срабатывает.
Смотрю на каунтерсы, а они не меняются:
# ipfw show
00100 5848 10090294 allow ip from any to any via lo0
00105 0 0 count ip from any to any proto udp out xmit em1
00110 0 0 count ip from any to any src-port 67 out xmit em1.512
00115 3 1143 count ip from any to any dst-port 67 in via em1.512
00120 0 0 count ip from any to any out via em1.512
при этом tail /var/log/dhcpd.log :
May 12 13:51:16 <daemon.info> test dhcpd: DHCPREQUEST for 172.18.27.5 from 00:1b:24:45:44:52 (tazik) via em1.512
May 12 13:51:16 <daemon.info> test dhcpd: DHCPACK on 172.18.27.5 to 00:1b:24:45:44:52 (tazik) via em1.512
и tazik получает ответ, и tcpdump видит пакет, и ng_tee на уровне ng_ether все видит, а ipfw не фиксирует.Уже и ipfw включил в ядро, добавив опции:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=50
options LIBALIAS
options DUMMYNET
а все одно.Проверил дома (там таже версия) все считается, а на работе нет. Куда рыть уже не знаю.
Как починить ipfw чтобы он начал срабатывать на исходящем правиле?!
Хочу добавить, что исходящие icmp пакеты ipfw все-таки регистрирует.
Но вот непонятно почему udp игнорирует?!
> Хочу добавить, что исходящие icmp пакеты ipfw все-таки регистрирует.
> Но вот непонятно почему udp игнорирует?!DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются через BPF. От сюда и ограничение, чтобы ipfw мог видеть и блокировать такие пакеты, вам нужно это делать на layer2. Читайте про net.link.ether.ipfw.
> DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются
> через BPF. От сюда и ограничение, чтобы ipfw мог видеть и
> блокировать такие пакеты, вам нужно это делать на layer2. Читайте про
> net.link.ether.ipfw.Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им могут фильтроваться, но не формироваться и не отправляться пакеты?
И как может не участвовать стек IP, если dhcp пакет имеет заголовки вплоть до L7?С другой стороны, на машине, на которой счетчики исправно растут (о чем я упоминал ранее) значение переменной net.link.ether.ipfw = 0.
Ну и все статьи о "net.link.ether.ipfw" касаются фильтрации по MAC. А мне это ни к чему. Я не знаю MAC-ов. В том смысле что какие есть, все хороши.
>> DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются
>> через BPF. От сюда и ограничение, чтобы ipfw мог видеть и
>> блокировать такие пакеты, вам нужно это делать на layer2. Читайте про
>> net.link.ether.ipfw.
> Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им
> могут фильтроваться, но не формироваться и не отправляться пакеты?Прочтите man 4 bpf
> И как может не участвовать стек IP, если dhcp пакет имеет заголовки
> вплоть до L7?DHCP клиент формирует весь пакет со всеми заголовками и отправляет его прямо в интерфейс используя BPF и минуя IP стек.
> С другой стороны, на машине, на которой счетчики исправно растут (о чем
> я упоминал ранее) значение переменной net.link.ether.ipfw = 0.В приведённом вами выводе счётчики растут только для входящих пакетов. Так как исходящий пакет отправляется мимо IP стека, PFIL хук файрвола не вызывается.
PFIL хуки вызываются из функций IP стека ip_input(), ip_output() и ip_tryforward(). В случае отправки пакета через BPF, пакет минует IP стек и отправляется из ether_output(). Чтобы файрвол увидел этот пакет, PFIL хук должен быть вызван из ether_output(), а это происходит только при включенном net.link.ether.ipfw.
Для входящих DHCP пакетов ситуация немного другая. Приложение, использующее BPF видит все пакеты, настроенные в фильтре, но изъять пакет из стека оно не может. Поэтому, т.к. пакет является IP пакетом, он попадает в ip_input(), а от туда уже в файрвол.
> Ну и все статьи о "net.link.ether.ipfw" касаются фильтрации по MAC. А мнене
> это ни к чему. Я не знаю MAC-ов. В том смысле
> что какие есть, все хороши.На layer2 ipfw может выполнять бОльшую часть всех действий, которые он умеет, за исключением nat и fwd. Он точно так же парсит все пакеты до заголовков транспортного уровня и правила могут матчить по всем параметрам, которые доступны в layer3.
Фильтрация по MAC адресам тут является просто дополнительной возможностью, т.к. у пакета ещё не отброшен ethernet заголовок.
> DHCP клиент формирует весь пакет со всеми заголовками и отправляет его прямо
> в интерфейс используя BPF и минуя IP стек.Только в моем случае "сервер".
> В приведённом вами выводе счётчики растут только для входящих пакетов. Так как
> исходящий пакет отправляется мимо IP стека, PFIL хук файрвола не вызывается.Да, счетчики я приводил для проблемной машины. На другой счет ведется. Но тут после Вашего сообщения вспомнил, что на проблемной DHCP сервер отдает все бродкастом.
И точно, если отключить "always-broadcast off;", то счетчики считают, правда только offer-ы, аки улетают неучтенными :)
А в случае с "always-broadcast on;" не считают ничего.В общем пошел читать. Направление похоже верное ;)
>>> Читайте про net.link.ether.ipfw.Благодарю за информацию. После установки этой переменной в 1 счетчики нормально считают весь исходящий трафик.
>> Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им
>> могут фильтроваться, но не формироваться и не отправляться пакеты?
> Прочтите man 4 bpfАга!
A packet can be sent out on the network by writing to a bpf file descriptor.То есть isc-dhcp пишет в дескриптор символьного устройства, не в сокет или куда, а именно в дескриптор /dev/bpf.
Понял. Благодарю.