tranger Posted June 14, 2019 Posted June 14, 2019 (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 June 14, 2019 by tranger Вставить ник Quote
jffulcrum Posted June 14, 2019 Posted June 14, 2019 Ну,для начала директива connlimit работает лишь при указании -p tcp Вставить ник Quote
orlik Posted June 14, 2019 Posted June 14, 2019 Видя такое , первое что хочется сделать. это спросить "а зачем ?". Вставить ник Quote
tranger Posted June 14, 2019 Author Posted June 14, 2019 31 минуту назад, orlik сказал: Видя такое , первое что хочется сделать. это спросить "а зачем ?". Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Вставить ник Quote
NewUse Posted June 14, 2019 Posted June 14, 2019 ну для этого есть авторизация и настройки сервера, не надо сюда фаерволл приплетать. Вставить ник Quote
pppoetest Posted June 14, 2019 Posted June 14, 2019 3 минуты назад, tranger сказал: Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Это дело не Netfilter Вставить ник Quote
tranger Posted June 14, 2019 Author Posted June 14, 2019 На самом сервере авторизацию сделать нельзя, сервер не мой, доступа нет Вставить ник Quote
alibek Posted June 14, 2019 Posted June 14, 2019 6 минут назад, tranger сказал: Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Если хотя бы минимально подумать головой, то такой вопрос бы даже не возник, потому что: 1. Сессии это TCP. А ряд сервисов использует UDP, в котором сессий нет. 2. Сессия это не только видео. Это еще и EPG. А может даже и интернет. 3. А еще есть прокси и NAT. 3 минуты назад, tranger сказал: На самом сервере авторизацию сделать нельзя, сервер не мой, доступа нет Тогда нужно почитать про проксирование. Вставить ник Quote
sdy_moscow Posted June 14, 2019 Posted June 14, 2019 Не знаю как сейчас, но раньше без Conntrack connlimit не работал, проверьте что Conntrack включен. Вставить ник Quote
orlik Posted June 14, 2019 Posted June 14, 2019 5 hours ago, tranger said: Есть удалённый ТВ сервер. Нужно ограничить пользователей. 1 абонент должен смотреть не больше 1 канала одновременно. Как уже посоветовали - это нужно селать на стороне сервера и ограничивать там. Это убдет правильнее иэффективее работать 5 hours ago, sdy_moscow said: Не знаю как сейчас, но раньше без Conntrack connlimit не работал, проверьте что Conntrack включен. Угу , и у клиента получится что пока старая запись не протухнет , новая не начнет работать, при переключении каналов по несколько секунд будет пустой экран Вставить ник Quote
sdy_moscow Posted June 14, 2019 Posted June 14, 2019 @orlik А дурное дело оно не хитрое.... Вставить ник Quote
orlik Posted June 15, 2019 Posted June 15, 2019 Ну типичный вариант, когда пытаются решить проблему не с той стороны Вставить ник Quote
NiTr0 Posted June 15, 2019 Posted June 15, 2019 19 часов назад, alibek сказал: 1. Сессии это TCP. А ряд сервисов использует UDP, в котором сессий нет с т.з. коннтрака - у удп сессии тоже есть. только своеобразные (все пакеты с одного src порта - одна сессия) 14 часов назад, orlik сказал: Угу , и у клиента получится что пока старая запись не протухнет , новая не начнет работать, при переключении каналов по несколько секунд будет пустой экран tcp - нет сессия нормаьно завершается, и начинается новая). udp - могут быть варианты (т.к. понятия "завершение сессии" там нет, только по таймауту). а вот если tcp сессия помрет (ну там внезапный ребут) - то останется висеть зо окончания таймаута (по дефолту - сутки). в целом в общем костыли, которые впрочем можно как-то заставить работать, но криво. Вставить ник Quote
tranger Posted June 15, 2019 Author Posted June 15, 2019 То что подход неправильный - это понятно. Самое идеальное решение, как многие написали, ограничить доступ со стороны сервера. Но к сожалению возможности такой нет и не появится. Решил задачу проксированием. Спасибо всем за ответы. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.