Как сделать ограничение подключений с 1 ip: при новом соединение должно закрываться самое старое?

В UDP нет соединений.

IMHO без подвывертов не выйдет. Конечные автоматы можно на ip_recent собирать, например детектить совпадения IP и писать в лог. А дальше уже логи скриптами парсить.

Только в UDP по-моему кроме датаграмм ничего нет.

Ага, какие еще соединения у UDP. И даже для TCP это извращение и не делается iptables. Это только скриптами спуфленые RST пакеты отправлять.

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

PS: Если у ТС точно протокол UDP и при этом есть какие-то сессии - значит это внутренние сессии самой софтины и «коннект висеть» может только по её внутренним причинам.

С одной стороны вы хотите ограничить число коннектов, то есть у вас есть клиенты, пытающиеся установить больше соединений, чем надо. С другой стороны желаете закрывать старые соединения. При этом, получается, что закрывать нужно «при зависании клиента, обрыве связи и т.п.», интерестно, каким образом сервер должен узнавать о зависании клиента?

Не знаю, в связи с чем именно у вас возникла потребность в ограничении числа соединений, но, видимо, сервер (демон) не справляется с болшим число сокетов. Но, не дать установить соедиенение легко (DROP-пакета), а вот закрыть коннект (закрыть сокет и освободить выделенные для данного подключения ресурсы) с помощью iptables как-то маловероятно.

ИМХО, проще всего научится как-то определять, что произошло «зависание клиента» и для этого ip-адреса на время добавлять правило (напрямую или через ipset), разрешающее большее кол-во соединений.

Соединений нет, а записи в conntrack'е есть. И "-m connlimit" смотрит по этим записям. В отличии от tcp, udp-записи из conntrack'а исчезают через, ЕМНИП, 5 минут отсутствия пакетов и не раньше. Видимо это и есть «коннект ещё долгое время виден с сервера».

В общем-то да. Ну тогда только чем-нибудь удалять записи из нетфильтра. iptables этого не умеет ес-но, не его задача. Но как я уже говорил - правильно это сервисом решать, а не через *опу.

м.б. это как-то иначе зовётся, это что видно в сетевой активности в oupost firewall (в винде). для debian я нагуглил аналог- iptstate - показывает эти же *соединения*, и там и там их можно, например закрыть и т.д.

тут неважно, из-за чего старые коннекты висят - из-за зависания, или из-за умышленного создания. код сервера очень неоптимален, если не выйдет ограничить внешними средставим, буду копаться в нём.. определить именно «зависание» без копания тоже не выйдет..

м.б. это как-то иначе зовётся, это что видно в сетевой активности в oupost firewall (в винде). для debian я нагуглил аналог- iptstate - показывает эти же *соединения*, и там и там их можно, например закрыть и т.д.
и да, мне не обязательно через iptables, важно что бы действовало.
через сам сервер (приложение), конечно можно наверно, используется сет. библиотека RakNet, м.б. там и есть что-то такое..

Соединений нет, а записи в conntrack'е есть. И "-m connlimit" смотрит по этим записям. В отличии от tcp, udp-записи из conntrack'а исчезают через, ЕМНИП, 5 минут отсутствия пакетов и не раньше. Видимо это и есть «коннект ещё долгое время виден с сервера».

Да. Но всё равно conntrack не будет на 100% правильно решать сабжевую проблему. В зависимости от реализации программы, которая устанавливает соединения, он может несколько разных с точки зрения логики программы соединений принять за одно. И наоборот.

тут неважно, из-за чего старые коннекты висят

Неважно из-за чего. Важно как вы формализуете понятие «коннект висит». Потому что вы хотите, чтобы при зависании коннекта сервер сбросил старые коннекты и принял новые, а не при зависании коннекта, сервер наоборот, не принимал новые коннекты, а держал старые.

iptstate это «морда» с conntrack'у. И нельзя там закрыть udp соединение, можно только удалить из conntrack эту запись. Но серверу на это будет безразлично. Так что лучше копайтесь в сервере.

вы хотите, чтобы при зависании коннекта сервер сбросил старые коннекты и принял новые, а не при зависании коннекта, сервер наоборот, не принимал новые коннекты, а держал старые.

нет, неважно что с ними - зависли или нет. например, человек открывает 3 экземпляра клиента - работают. открывает 4- й - и первый запущенный дисконнектится. тоже должно случатся, если у него 3 раза что-то зависало к примеру.

Connection tracking

Because it lacks sequence numbers, udp is known as a «stateless» protocol . However, this does not mean we can't track udp connections. There is still other useful information we can utilize.

До сего момента я считал, что libastral.so - это такая смешная шутка линуксоидов.

conntrack не отслеживает классические соединения, он лишь отслеживает UDP-активность между определёнными сокетами. Вот если бы задача стояла бороться с DoS-ом, то conntrack тебе в руки, а «удалять старые сессии» - это странно, учитывая что сессий как таковых нет.

человек открывает 3 экземпляра клиента - работают. открывает 4- й - и первый запущенный дисконнектится

Человеческим образом решить это можно только на уровне сервера.