Traffic accounting, arp managing and so on

Автор: Xemul Дата: 22.07.2003 12:49 Поискал в инете статьи на тему администрирования шлюза.
Решить надо было 3 проблемы:
1. Подсчет траффика.
2. Ограничение траффика.
3. Привязка по МАКам.

1й вопрос довольно детально описан, но не без геморроя.
2й не нашел вообще - каким образом я могу сказать в правиле iptables, что "если в этой цепочке кол-во байт прошедших туда больше чем ХХХ то -j DROP"
На 3й вопрос дофига ответов начиная от "40 литровую клизму с 1кг патефонных иголок нарушителю" до "патчим ядро и..."
Хотелось бы узнать как это решается средствами iptables.
Re: Traffic accounting, arp managing and so on 22.07.2003 18:49Alx На самом деле решение вопросов 1 и 2 объединяется и решается совместно системой учета траффика. Что касается 3 вопроса, то нужно прояснить, в связи с чем он поднимается. MAC легко меняется и его привязка в большинстве случаев защитит только от ламера.
Re: Traffic accounting, arp managing and so on 22.07.2003 18:59Xemul 1 и 2 вопросы - хотелось бы решить их средствами iptables. Улыбка
А если без них - тогда посоветуйте в направлении какой системы копать.

Привязка - у юзерей есть возможность поменять только IP. Ж)
Re: Traffic accounting, arp managing and so on 22.07.2003 19:12Woodoo Xemul писал(а):

> Поискал в инете статьи на тему администрирования шлюза.
> Решить надо было 3 проблемы:
> 1. Подсчет траффика.
> 2. Ограничение траффика.
> 3. Привязка по МАКам.

Задачи сформулированы некорректно. Какой именно "трафик" ты
собираешься учитывать (вообще, почта, http, nntp etc)? Сколько клиентов? 2? А чуть позже? Какой режим работы планируется? ;-)

> 1й вопрос довольно детально описан, но не без геморроя.

iptables сделать-то можно.
Но - "не без геморроя". Есть другие решения. Но для правильной
оценки - нужно корректно сформулировать задачи и исходные условия.

> 2й не нашел вообще - каким образом я могу сказать в правиле
> iptables, что "если в этой цепочке кол-во байт прошедших туда
> больше чем ХХХ то -j DROP"

Напрямую - нет. Но написать скрипт можно.

> На 3й вопрос дофига ответов начиная от "40 литровую клизму с
> 1кг патефонных иголок нарушителю" до "патчим ядро и..."
> Хотелось бы узнать как это решается средствами iptables.

Уперся в свои iptables. )))
Прочитай ветку "Use proxy" на этом форуме - там много разносторонних мнений. Как, впрочем, и путей решения.
Re: Traffic accounting, arp managing and so on 22.07.2003 19:37Alx Xemul писал(а):


> Привязка - у юзерей есть возможность поменять только IP. Ж)

Если у юзверей Линукс/Юникс, то MAC меняется нажатием клавиш на клавиатуре, если Вынь - то можно и перепрограммировать флэшку на сетевой карте. Было бы желание...
Re: Traffic accounting, arp managing and so on 22.07.2003 19:37Xemul > Xemul писал(а):
>
> > Поискал в инете статьи на тему администрирования шлюза.
> > Решить надо было 3 проблемы:
> > 1. Подсчет траффика.
> > 2. Ограничение траффика.
> > 3. Привязка по МАКам.
>
> Задачи сформулированы некорректно. Какой именно "трафик" ты
> собираешься учитывать (вообще, почта, http, nntp etc)?
> Сколько клиентов? 2? А чуть позже? Какой режим работы
> планируется? ;-)

Любой траффик - все что проходит через FORWARD разделяя по IP.
Ну это все ерунда - тут я уже нашел себе приемлемое решение.
А режим работы планируется самый что ни на есть боевой - юзеры сломя голову лезут в инет за информацией, мне надо подсчитать кто скока накачал (в каждый нужный момент времени) и если кто-то в определенное время пытается начать качать 101 мег из 100 оплаченных тутже его обрубить, а не ждать неопределенное время пока какой-нить cron поднимет какой-нить скрипт который увидит что трафика уже перекачано и вставит в нужное место -j DROP. Кстати скажу что фраза "кто-то начинает качать 101й мег из 100 тутже его обрубить" на самом деле означает "как только счетчик в определенной таблице превышает 104657600 байт тут же вставить первым правилом в эту таблицу -j DROP (например)"

> > 1й вопрос довольно детально описан, но не без геморроя.
>
> iptables сделать-то можно.
> Но - "не без геморроя". Есть другие решения. Но для
> правильной
> оценки - нужно корректно сформулировать задачи и исходные
> условия.

Условия сформулировал выше. Если что непонятно - говорите уточню. Улыбка

> > 2й не нашел вообще - каким образом я могу сказать в
> правиле
> > iptables, что "если в этой цепочке кол-во байт прошедших
> туда
> > больше чем ХХХ то -j DROP"
>
> Напрямую - нет. Но написать скрипт можно.

Это интересно - хотябы идею подкинте. Особо важно что этот скрипт не должен опрашивать состояние цепочек каждые дцать минут, а сразу по превышении трафика обрезать канал.

> > На 3й вопрос дофига ответов начиная от "40 литровую клизму
> с
> > 1кг патефонных иголок нарушителю" до "патчим ядро и..."
> > Хотелось бы узнать как это решается средствами iptables.
>
> Уперся в свои iptables. )))
> Прочитай ветку "Use proxy" на этом форуме - там много
> разносторонних мнений. Как, впрочем, и путей решения.

Ну с МАКом я тоже разгребся Улыбка Больше этот вопрос меня не мучает.
А в iptables я не уперся а просто не хочу нагружать на комп лишних пакетов - чем сложнее система тем легче ее вывести из строя Улыбка
Re: Traffic accounting, arp managing and so on 22.07.2003 19:42Xemul > > Привязка - у юзерей есть возможность поменять только IP.
> Ж)
>
> Если у юзверей Линукс/Юникс, то MAC меняется нажатием клавиш
> на клавиатуре, если Вынь - то можно и перепрограммировать
> флэшку на сетевой карте. Было бы желание...
Да при желании можно натянуть чулки на морду, взять лом и полезть патчить мозги админу. Улыбка Задача не в том чтоб заткнуть все дыры, а в том чтоб заткнуть существующие и потенциальные. Дело в том что подготовка существующих юзерей пока не позволяет им менять МАКИ а потому достаточно ограничиться правилами "если IP == IP1 и MAC == MAC1 тогда считать траффик для Вани Пупкина, если IP == ... для Васи Кукуева иначе считать что юзер поменял себе IP, выдать это в лог и забить на пакет".
Re: Traffic accounting, arp managing and so on 22.07.2003 19:55Woodoo Xemul писал(а):

> Привязка - у юзерей есть возможность поменять только IP. Ж)

Сущие мелочи.
И как ты их идентифицировать собираешься?
Про dns, dhcp - сразу забудь. )
Re: Traffic accounting, arp managing and so on 22.07.2003 19:58Xemul > > Привязка - у юзерей есть возможность поменять только IP.
> Ж)
>
> Сущие мелочи.
> И как ты их идентифицировать собираешься?
> Про dns, dhcp - сразу забудь. )
>

Итак. Я прихожу на хату к юзеру и говорю - вот тебе карточка, вот IP. Как я уже отметил юзер пока маленький и сменить МАК не сможет, а вот IP сможет.
Поэтому я в правилах iptables вставляю что-то типа
-A FORWARD -m mac XX]:/X]:/X]:/X]:/X]:/X -s XX.XX.XX.XX
где все XXXXX соответствуют друг другу.
Это не проблема.
Проблема в отсекании трафика.
Re: Traffic accounting, arp managing and so on 22.07.2003 21:20Woodoo Xemul писал(а):

> Итак. Я прихожу на хату к юзеру и говорю - вот тебе карточка,
> вот IP. Как я уже отметил юзер пока маленький и сменить МАК не
> сможет, а вот IP сможет.

Это не существенно, считай, что уже может.

> Поэтому я в правилах iptables вставляю что-то типа
> -A FORWARD -m mac XX]:/X]:/X]:/X]:/X]:/X -s XX.XX.XX.XX
> где все XXXXX соответствуют друг другу.
> Это не проблема.

Это проблема. При системном подходе, я не представляю, как ты
собираешься учитывать 10-100-1000 пользователей. С учетом, что,
возможно, тебе понадобится инструмент групповых политик - совсем
"Ой!".

> Проблема в отсекании трафика.

Смотри в сторону соответствующих служб и проксей.
В действительности iptables - это "тонкий" инструмент для совершенно определенного круга задач. Исходные задачи, которые ты ставишь не совсем подходят для решения с помощью iptables. Они никак не могут решить, например, авторизацию по имени+пароль и т.д.

Может, все-таки очертишь круг планируемых сервисов для пользователей?
Re: Traffic accounting, arp managing and so on 22.07.2003 21:52Xemul > > Итак. Я прихожу на хату к юзеру и говорю - вот тебе
> карточка,
> > вот IP. Как я уже отметил юзер пока маленький и сменить
> МАК не
> > сможет, а вот IP сможет.
>
> Это не существенно, считай, что уже может.
>
> > Поэтому я в правилах iptables вставляю что-то типа
> > -A FORWARD -m mac XX]:/X]:/X]:/X]:/X]:/X -s XX.XX.XX.XX
> > где все XXXXX соответствуют друг другу.
> > Это не проблема.
>
> Это проблема. При системном подходе, я не представляю, как ты
>
> собираешься учитывать 10-100-1000 пользователей. С учетом,
> что,
> возможно, тебе понадобится инструмент групповых политик -
> совсем
> "Ой!".

Ну я так полагаю что если имитировать какой-нить двоичный поиск в таблицах, то можно находить нужную мне за log(числа_пользователей), то есть при 100 юзерях это 4-5 проверок, что не так уж и много.

> > Проблема в отсекании трафика.
>
> Смотри в сторону соответствующих служб и проксей.
> В действительности iptables - это "тонкий" инструмент для
> совершенно определенного круга задач. Исходные задачи, которые
> ты ставишь не совсем подходят для решения с помощью iptables.
> Они никак не могут решить, например, авторизацию по
> имени+пароль и т.д.
>
> Может, все-таки очертишь круг планируемых сервисов для
> пользователей?

Ок. Вот требуемые сервисы - юзеры должны свободно пользовать инет. Для этого предполагается юзать SNAT, ну и для подсчета траффика byte counters на таблицах. В будущем может быть поставлю squid. У меня уже сейчас стоит машина за которой сидит еще одна и первая дает неограниченый доступ второй, причем еще и считает траффик. В планируемой сети будет ровно то же самое, но за шлюзом будет стоять не один, а максимум 254 компа. Вот собсно и все. Заморачиваться на счет того что будет 1000 или более юзерей не стоит - если в этом месте возникнет столько желающих, то нас быстренько приберет к рукам конкурирующая фирма Улыбка))
Re: Traffic accounting, arp managing and so on 22.07.2003 22:04Vladimir Dyakov Xemul, могу вам порекомендовать _отличное_ место:
[lartc.org]
А также, ищите на opennet.ru, например тут: [www.opennet.ru]
Re: Traffic accounting, arp managing and so on 22.07.2003 22:10Xemul ОГРОМНОЕ СПАСИБО!
Именно то что нужно!
Конкуренты умрут от зависти Улыбка))
Re: Traffic accounting, arp managing and so on 22.07.2003 22:18Vladimir Dyakov Можно ещё поискать в Административном и Общем форуме сообщения МихаилZ - он неоднократно давал свои цепочки от iptables. Имхо, крайне полезно для начинающего посмотреть, как работает на примере. Особенно, если это _отлаженный_, _реально_работающий_ пример ;-)
Re: Traffic accounting, arp managing and so on 22.07.2003 23:11Woodoo (пробегая мимо)

...что-то мне не встречались провайдеры, у которых при количестве клиентов N<=254 все только на iptables реализовано...
Ж)
Re: Traffic accounting, arp managing and so on 23.07.2003 07:28Alx Ну вот, такую дискуссию проспал в буквальном смысле слова ;-)
2 Xemul: собираешься домашнюю сеть делать?
Re: Traffic accounting, arp managing and so on 23.07.2003 08:17Vladimir Dyakov Кому надо мощный _учёт_ трафика: [freeradius.org]
Re: Traffic accounting, arp managing and so on 23.07.2003 18:47Xemul > Ну вот, такую дискуссию проспал в буквальном смысле слова
> ;-)
> 2 Xemul: собираешься домашнюю сеть делать?
Типа того Улыбка Все уже работает на одних только iptables. Все - в смысле все что надо кроме одного - никак не могу сделать автоматический контроль за превышением входящего/исходящего траффика по определенной таблице. То есть iptables -L some_table -x -v, смотрю bytes, и как только больше заданного - надо "что-то" сделать... Неужели у меня единственный выход только через освоение какой-нить биллинговой системы?

Кстати насчет lartc.org я походу погорячился Улыбка Там много полезного, кое что даже очень, но вот ЭТОГО я там не нашел Грустный
Re: Traffic accounting, arp managing and so on 23.07.2003 18:52Xemul > (пробегая мимо)
>
> ...что-то мне не встречались провайдеры, у которых при
> количестве клиентов N<=254 все только на iptables
> реализовано...
> Ж)

Дык мне провайдерить не надо Улыбка
У меня запросы совсем скромные и очень не хочется для их решения ковырять много систем сразу...
Re: Traffic accounting, arp managing and so on 23.07.2003 18:58Xemul BTW!
С рассылке netfilter.org мне порекомендовали глянуть quota match support, что я сделал и вполне доволен Улыбка
Для текущих нужд - самое то Улыбка
RSS-материал