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

iptables лимит подключений

Всем привет!
Имеется роутер на centos7
eth0.100 - мир
eth0.200 - локалка
Клиенты получают белые ip-адреса допустим из диапазона 1.1.1.0/24
На роутере настроена маршрутизация (ната нет)
Есть удалённый хост 2.2.2.2 (находится во внешке)
Задача: каждый пользователь из подсети 1.1.1.0/24 должен иметь не более 1 соединения с удалённым хостом 2.2.2.2.
То есть если кол-во соединений клиента 1.1.1.5 с хостом 2.2.2.2 превышает 1, то пакеты дропаются.
Как можно это реализовать? Нужно увязать с ipset.
Экспериментировал, делал:
iptables -A FORWARD -i eth0.100 -m connlimit --connlimit-above 1 -m set --match-set ipaddr src,dst -j DROP
и много разных вариантов перепробовал.
Подскажите, как решить задачу?

Edited by tranger

Share this post


Link to post
Share on other sites

Ну,для начала директива connlimit работает лишь при указании -p tcp

Share this post


Link to post
Share on other sites

Видя такое , первое что хочется сделать. это спросить "а зачем ?".

Share this post


Link to post
Share on other sites
31 минуту назад, orlik сказал:

Видя такое , первое что хочется сделать. это спросить "а зачем ?".

Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. 

Share this post


Link to post
Share on other sites

ну для этого есть авторизация и настройки сервера, не надо сюда фаерволл приплетать.

Share this post


Link to post
Share on other sites
3 минуты назад, tranger сказал:

Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. 

Это дело не Netfilter

Share this post


Link to post
Share on other sites

На самом сервере авторизацию сделать нельзя, сервер не мой, доступа нет

Share this post


Link to post
Share on other sites
6 минут назад, tranger сказал:

Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. 

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

1. Сессии это TCP. А ряд сервисов использует UDP, в котором сессий нет.

2. Сессия это не только видео. Это еще и EPG. А может даже и интернет.

3. А еще есть прокси и NAT.

 

3 минуты назад, tranger сказал:

На самом сервере авторизацию сделать нельзя, сервер не мой, доступа нет

Тогда нужно почитать про проксирование.

Share this post


Link to post
Share on other sites

 Не знаю как сейчас, но раньше без Conntrack connlimit не работал, проверьте что Conntrack включен.

Share this post


Link to post
Share on other sites
5 hours ago, tranger said:

Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. 

Как уже посоветовали - это нужно селать на стороне сервера и ограничивать там. Это убдет правильнее иэффективее работать

 

5 hours ago, sdy_moscow said:

 Не знаю как сейчас, но раньше без Conntrack connlimit не работал, проверьте что Conntrack включен.

Угу , и у клиента получится что пока старая запись не протухнет , новая не начнет работать, при переключении каналов по несколько секунд будет пустой экран

Share this post


Link to post
Share on other sites

Ну типичный вариант, когда пытаются решить проблему не с той стороны 

Share this post


Link to post
Share on other sites
19 часов назад, alibek сказал:

1. Сессии это TCP. А ряд сервисов использует UDP, в котором сессий нет

с т.з. коннтрака - у удп сессии тоже есть. только своеобразные (все пакеты с одного src порта - одна сессия)

 

14 часов назад, orlik сказал:

Угу , и у клиента получится что пока старая запись не протухнет , новая не начнет работать, при переключении каналов по несколько секунд будет пустой экран

tcp - нет сессия нормаьно завершается, и начинается новая). udp - могут быть варианты (т.к. понятия "завершение сессии" там нет, только по таймауту).

а вот если tcp сессия помрет (ну там внезапный ребут) - то останется висеть зо окончания таймаута (по дефолту - сутки).

 

в целом в общем костыли, которые впрочем можно как-то заставить работать, но криво.

Share this post


Link to post
Share on other sites

То что подход неправильный - это понятно. Самое идеальное решение, как многие написали, ограничить доступ со стороны сервера. Но к сожалению возможности такой нет и не появится.
Решил задачу проксированием.
Спасибо всем за ответы.

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