tranger Posted June 14, 2019 (edited) · Report post Всем привет! Имеется роутер на 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 June 14, 2019 by tranger Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jffulcrum Posted June 14, 2019 · Report post Ну,для начала директива connlimit работает лишь при указании -p tcp Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
orlik Posted June 14, 2019 · Report post Видя такое , первое что хочется сделать. это спросить "а зачем ?". Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tranger Posted June 14, 2019 · Report post 31 минуту назад, orlik сказал: Видя такое , первое что хочется сделать. это спросить "а зачем ?". Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted June 14, 2019 · Report post ну для этого есть авторизация и настройки сервера, не надо сюда фаерволл приплетать. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
pppoetest Posted June 14, 2019 · Report post 3 минуты назад, tranger сказал: Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Это дело не Netfilter Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tranger Posted June 14, 2019 · Report post На самом сервере авторизацию сделать нельзя, сервер не мой, доступа нет Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alibek Posted June 14, 2019 · Report post 6 минут назад, tranger сказал: Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Если хотя бы минимально подумать головой, то такой вопрос бы даже не возник, потому что: 1. Сессии это TCP. А ряд сервисов использует UDP, в котором сессий нет. 2. Сессия это не только видео. Это еще и EPG. А может даже и интернет. 3. А еще есть прокси и NAT. 3 минуты назад, tranger сказал: На самом сервере авторизацию сделать нельзя, сервер не мой, доступа нет Тогда нужно почитать про проксирование. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sdy_moscow Posted June 14, 2019 · Report post Не знаю как сейчас, но раньше без Conntrack connlimit не работал, проверьте что Conntrack включен. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
orlik Posted June 14, 2019 · Report post 5 hours ago, tranger said: Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Как уже посоветовали - это нужно селать на стороне сервера и ограничивать там. Это убдет правильнее иэффективее работать 5 hours ago, sdy_moscow said: Не знаю как сейчас, но раньше без Conntrack connlimit не работал, проверьте что Conntrack включен. Угу , и у клиента получится что пока старая запись не протухнет , новая не начнет работать, при переключении каналов по несколько секунд будет пустой экран Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sdy_moscow Posted June 14, 2019 · Report post @orlik А дурное дело оно не хитрое.... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
orlik Posted June 15, 2019 · Report post Ну типичный вариант, когда пытаются решить проблему не с той стороны Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted June 15, 2019 · Report post 19 часов назад, alibek сказал: 1. Сессии это TCP. А ряд сервисов использует UDP, в котором сессий нет с т.з. коннтрака - у удп сессии тоже есть. только своеобразные (все пакеты с одного src порта - одна сессия) 14 часов назад, orlik сказал: Угу , и у клиента получится что пока старая запись не протухнет , новая не начнет работать, при переключении каналов по несколько секунд будет пустой экран tcp - нет сессия нормаьно завершается, и начинается новая). udp - могут быть варианты (т.к. понятия "завершение сессии" там нет, только по таймауту). а вот если tcp сессия помрет (ну там внезапный ребут) - то останется висеть зо окончания таймаута (по дефолту - сутки). в целом в общем костыли, которые впрочем можно как-то заставить работать, но криво. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tranger Posted June 15, 2019 · Report post То что подход неправильный - это понятно. Самое идеальное решение, как многие написали, ограничить доступ со стороны сервера. Но к сожалению возможности такой нет и не появится. Решил задачу проксированием. Спасибо всем за ответы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
