[Sysadmins] netfilter_queue и increase socket buffer size by nfnl_rcvbufsiz()

[Sysadmins] netfilter_queue и increase socket buffer size by nfnl_rcvbufsiz()

[Караваев Павел]

Приветствую!
Пытаю вот такую штуку: https://github.com/ircop/nfq_filter
Принцип работы примерно такой: на пограничном шлюзе весь http трафик зеркалируется через отдельную сетевуху на соседний сервер с nfq_filter:

iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j TEE --gateway 192.168.0.2

На 192.168.0.2 этот трафик направляется в этот nfq_filter:

/sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/0 -p tcp -m tcp --dport 80 -j NFQUEUE --queue-num 0 --queue-bypass

Первая попытка была на ALT Linux 5.0.1 Ark Server. Закончилось тем, что через 10-30 сек после запуска фильтра, на его вход переставали приходить пакеты, хотя tcpdump на сетевом интерфейсе их показывал. Аналогичная проблема возникала у автора, но через 1-2 часа после запуска. Автор решил ее методом перезапуска фильтра раз в полчаса :).

Не мудрствуя лукаво, я решил попробовать под другим дистрибутивом, поставил ubuntu. Теперь этой проблемы нет, но возникла другая: в лог фильтра несколько раз в секунду сыплется:

ERROR: ENOBUFS: App is not fast enough, increase socket buffer size by nfnl_rcvbufsiz()

т.е. фильтр не успевает обрабатывать пакеты, приходящие из ядра, и они не умещаются в буфере. При этом поток трафика на сетевом интерфейсе не превышает 30 мбит/с, ядра процессора загружены не более, чем на 40-50%, Load Average 1.1-1.5, памяти свободной много. Размер буфера фильтра увеличивал до уже неразумных пределов, на результат не повлияло. Учитывая, что предыдущая попытка предпринималась на этом же железе и тогда такой проблемы не было, склоняюсь к мысли, что дело не в железных ресурсах. Может где что подкрутить?

Re: [Sysadmins] netfilter_queue и increase socket buffer size by nfnl_rcvbufsiz()

[Anton Farygin]

Есть понимание, что nqf_filter нерабочий, хотя я его в совсем другом 
продукте видел, и он там работает - но код там походу отличается, всё 
закрытов в бинарях.

Можно попинать по поводу GPL:
http://ideco.ru/products/ispcf

On 22.01.2015 14:49, Караваев Павел wrote:
> Приветствую!
> Пытаю вот такую штуку: https://github.com/ircop/nfq_filter
> Принцип работы примерно такой: на пограничном шлюзе весь http трафик зеркалируется через отдельную сетевуху на соседний сервер с nfq_filter:
>
> iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
>
> На 192.168.0.2 этот трафик направляется в этот nfq_filter:
>
> /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/0 -p tcp -m tcp --dport 80 -j NFQUEUE --queue-num 0 --queue-bypass
>
> Первая попытка была на ALT Linux 5.0.1 Ark Server. Закончилось тем, что через 10-30 сек после запуска фильтра, на его вход переставали приходить пакеты, хотя tcpdump на сетевом интерфейсе их показывал. Аналогичная проблема возникала у автора, но через 1-2 часа после запуска. Автор решил ее методом перезапуска фильтра раз в полчаса :).

А почему такой старый ALT Linux ? поставьте что-то посвежее. Для 
экспериментов можно взять это:

http://ftp.altlinux.ru/pub/people/rider/sisyphus-1.9.3-20150119-server-light-x86_64-ru-install-cd.iso


>
> Не мудрствуя лукаво, я решил попробовать под другим дистрибутивом, поставил ubuntu. Теперь этой проблемы нет, но возникла другая: в лог фильтра несколько раз в секунду сыплется:
>
> ERROR: ENOBUFS: App is not fast enough, increase socket buffer size by nfnl_rcvbufsiz()
>
> т.е. фильтр не успевает обрабатывать пакеты, приходящие из ядра, и они не умещаются в буфере. При этом поток трафика на сетевом интерфейсе не превышает 30 мбит/с, ядра процессора загружены не более, чем на 40-50%, Load Average 1.1-1.5, памяти свободной много. Размер буфера фильтра увеличивал до уже неразумных пределов, на результат не повлияло. Учитывая, что предыдущая попытка предпринималась на этом же железе и тогда такой проблемы не было, склоняюсь к мысли, что дело не в железных ресурсах. Может где что подкрутить?

А автор что говорит по этому поводу ?