Jump to content

Recommended Posts

Posted (edited)

Всем привет!
Имеется роутер на 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
Posted
31 минуту назад, orlik сказал:

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

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

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

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

Это дело не Netfilter

Posted
6 минут назад, tranger сказал:

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

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

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

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

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

 

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

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

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

Posted
5 hours ago, tranger said:

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

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

 

5 hours ago, sdy_moscow said:

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

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

Posted
19 часов назад, alibek сказал:

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

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

 

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

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

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

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

 

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

Posted

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.