Не знаю относительно «много ресурсов», но я представляю два варианта, либо при удалении пользователя идущие к нему пакеты будут DROP, либо REJECT. В случае с DROP мне вобще не понятно про ресурсы, если же REJECT и возникает icmp-пакет, то может быть на это и тратятся заметные ресурсы, но не думаю, что много.

Ну попробуйте посмотреть tcpdump'ом, возникает ли в момент отключения пользователя много icmp-пакетов.

Там DROP. До сих пор я не сталкивался с необходимостью использовать tcpdump. Видимо, сейчас придётся...

Ну, если это тот сервер, где куча самописных скриптов, то может дело в них, допустим при отключении пользователя начинают обрабатывать его статистику (загружают диск) и всё тормозит.

Удалить известные соединения можно при помощи утилиты conntrack.

Недавно обратил внимание, что при удалении активного пользователя из белого списка сервер начинает тормозить.

Может быть, у тебя в цепочке FORWARD таблицы filter слишком много записей, а правило типа

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

На NAT-сервере используется iptables+ipset(белый список) для контроля доступа пользователей в Инет.

Покажи правила, реализующие это, если советов выше не хватит.

Но подтверждение о доставке пиру не приходит, и это порождает флуд в сети до завершения таймаутов.

TCP/IP быстро утихнет, если не будет получать обратных пакетов, но флуд возможен в случае UDP. Современные торрент-клиенты зачастую используют UDP по дефолту.

Сервер тот самый, но сейчас вся статистика и прочие самописные штуки отключены.

До tcpdump пока не добрался.

2 anonymous:

Названное правило стоит в самом начале. Только ж соединение уже установлено. Так что все пакеты пройдут это правило.

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets                                                                                           
$IPTABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT                                                                                     
# Accept only for white listed adresses
$IPTABLES -A FORWARD -p ALL -i $LAN_IFACE -m set --match-set whitelist src,src -j fw_allow
$IPTABLES -A FORWARD -m limit --limit 1/hour --limit-burst 5 -j LOG --log-level notice --log-prefix "IPT FORWARD packet died: "

TCP/IP быстро утихнет, если не будет получать обратных пакетов, но флуд возможен в случае UDP. Современные торрент-клиенты зачастую используют UDP по дефолту.

И как с этим бороться?

Я правильно понял, что отключение фактически перекрывает новые сессии (--ctstate NEW), а все существующие спокойно продолжают докачивать трафик?

У сервера есть «белый» ip-адрес, или его NAT-ит провайдер?

А какие правила в bad_tcp_packets?

Только ж соединение уже установлено. Так что все пакеты пройдут это правило.

Используй утилиту conntrack для удаления лишних уже известных соединений.

И как с этим бороться?

Причина медленной работы пока не ясна, т.е. может дело и не во флуде, но вообще можно просто зарубить все, кроме TCP, если клиенты не играют в игры, не поднимают VPN и не используют DHT в торрентах.

Адрес сервера NAT-ит провайдер.

Я правильно понял, что отключение фактически перекрывает новые сессии (--ctstate NEW)

Если бы дело было только в файрволе, то да. Но там ещё и tc работает, который балансирует канал. Как было написано в руководстве по настройке tc — он не пускает всех, кого нет в списке.
Не знаю, как вынуть смысловую часть, поэтому вот он весь: http://pastebin.com/wii9CPK2

Причина медленной работы пока не ясна, т.е. может дело и не во флуде, но вообще можно просто зарубить все, кроме TCP, если клиенты не играют в игры, не поднимают VPN и не используют DHT в торрентах.

А это не заблокирует протокол мюторрента? Он же, вроде, UDP? Ну, понятно, что нужно будет разрешить 53 UDP. Честно, уж очень радикально звучит.

Используй утилиту conntrack для удаления лишних уже известных соединений.

conntrack -D -s $IP
conntrack -D -d $IP
Так? Правильно я понимаю, что это разорвёт TCP соединения, а UDP надо побороть как-то по другому?

А это не заблокирует протокол мюторрента? Он же, вроде, UDP?

Он и TCP может. При наличии HTTP трекеров для данного торрента будет даже вообще без UDP работать.

Честно, уж очень радикально звучит.

Не обязательно же навсегда его отключать, просто посмотреть, как это повлияет на нагрузку сервера :)

conntrack -D -s $IP conntrack -D -d $IP Так? Правильно я понимаю, что это разорвёт TCP соединения, а UDP надо побороть как-то по другому?

Это удалит соединения из таблицы conntrack, после чего эти пакеты, принадлежащие этим соединениям, не будут попадать под правило

$IPTABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT    

UDP это тоже коснется - в netfilter'е определены UDP-соединения для облегчения фильтрации UDP траффика.

О! Вот это круто. Спасибо!

Всё! проверил на практике — работает. После обрывов соединений тормоза исчезают за пару секунд.

блиин такая же проблема как убить UDP после закрытия клиенту инета??

tcp-reset только для TCP а UDP остается как его прекратить из вашего общения понял что надо писать IPTABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT и это решит мои проблемы??? а где именно пистаь до иди после или как??? а кроме этого еще что то надо писать?

conntrack -D -s $IP conntrack -D -d $IP

Если всё остальное сделано правильно, это оборвёт уже открытые соединения. В т.ч. UDP.

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD --source 192.168.93.0/24 -p tcp -j REJECT --reject-with tcp-reset

iptables -A FORWARD --source 192.168.93.0/24 -j DROP

//

а с каким пакетом идет этот conntrack у меня почемуто нету... OpenWrt

разрешающее правило на клиента под каким номером загонять???

разрешающее правило на клиента под каким номером загонять???

хотя оказывается есть

Package kmod-ipt-conntrack (3.10.49-1) installed in root is up to date.

разрешающее правило на клиента под каким номером загонять???

Это ты хорошо спросил :) думаешь, я твои правила по номерам знаю? Выкладывай все правила, тогда подумаем.

вот это все правила

1) iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

2) iptables -A FORWARD --source 192.168.93.0/24 -p tcp -j REJECT --reject-with tcp-reset

3) iptables -A FORWARD --source 192.168.93.0/24 -j DROP

вот

могу ли я так сделать? conntrack -D -s 192.168.93.11 conntrack -D -d 0.0.0.0/0

и как должно устанавливаться соединение? Как появится установленное соединение, которое разрешено, если всё, что не установлено дропается?

Добавим к этому, что клиенту достаточно поменять IP на другую подсетку и плевать он хотел на твои правила. Где политика по умолчанию?

Иными словами — в гугл, искать нормальный конфиг. Где-то здесь недалеко лежал мой конфиг в нескольких вариантах, но он пожалуй, сложноват, тебе нужен проще, из руководства по первоначальной настройке.

могу ли я так сделать? conntrack -D -s 192.168.93.11 conntrack -D -d 0.0.0.0/0

Можешь, кто ж тебе запретит. Пробуй, ничего страшного не получится :)