Видимо, в выходные я буду причесывать этот ужас.
Задачи, которые я должен решить:
1. При добавлении пользователя в IPN у него должны выставляться лимиты скорости
2. При изменении тарифного плана они должны меняться
3. Траффик, подсчитанный внешним сборщиком, должен сразу после подсчета ложиться в таблицы, при этом, в зависимости от типа подключения должен сбрасываться mpd или выставляться правила ipfw
Если кто-нибудь уже делал подобное, или хотя бы пытался разобраться в abills, или заинтересован в результате - пишите сюда, будем разбираться, раз уж автор не может. Патчи будут.
итак, итоги
-
Alex Povolotsky
- Сообщения: 26
- Зарегистрирован: Чт сен 21, 2006 3:16 pm
- Контактная информация:
-
Alex Povolotsky
- Сообщения: 26
- Зарегистрирован: Чт сен 21, 2006 3:16 pm
- Контактная информация:
(для себя)
Итак, какой вариант работы представляется мне оптимальным?
1. Для каждого тарифного плана делается набор пайпов, номера пайпов начинаются с 1000+10*номер_тарифного_плана
и таблица 1000+номер_тарифного_плана*10
пиринг селится в табл. 1
после чего делается до четырех (у меня есть только пиринг и мир, так что будем забивать пока на общность) правил типа
add 1010 pipe 1010 ip from table(1010) to table(1) via ${int_if} in
add 1011 pipe 1011 ip from table(1) to table(1010) via ${int_if} out
add 1012 pipe 1012 ip from table(1010) to not table(1) via ${int_if} in
add 1013 pipe 1013 ip from not table(1) to table(1010) via ${int_if} out
а пайпы выглядят как
pipe 1010 config mask src-ip 0xffffffff bw 10mbit/s
pipe 1011 config mask dst-ip 0xffffffff bw 10mbit/s
pipe 1012 config mask src-ip 0xffffffff bw 128kbit/s
pipe 1013 config mask dst-ip 0xffffffff bw 32kbit/s
после чего в linkupdown или в ipn enable достаточно просто включить/убрать адрес из соответствующей таблицы. Это также должно бы уменьшить нагрузку на ядро.
Далее. racct мы выключаем нафиг. Вместо этого прописываем каждому dv-логину статический IP (начало пула+uid, самое то), вешаем на непиринговый траффик ipacct, и вуаля, осталось только разобраться, как работает учет траффика. Соответственно, как только баланс уходит в ноль, мы просто вынимаем адрес из таблицы, не заботясь о том, висит он на vpn или на ipn. Порвать vpn тоже можно, если не лень. Пока - лень.
1. Для каждого тарифного плана делается набор пайпов, номера пайпов начинаются с 1000+10*номер_тарифного_плана
и таблица 1000+номер_тарифного_плана*10
пиринг селится в табл. 1
после чего делается до четырех (у меня есть только пиринг и мир, так что будем забивать пока на общность) правил типа
add 1010 pipe 1010 ip from table(1010) to table(1) via ${int_if} in
add 1011 pipe 1011 ip from table(1) to table(1010) via ${int_if} out
add 1012 pipe 1012 ip from table(1010) to not table(1) via ${int_if} in
add 1013 pipe 1013 ip from not table(1) to table(1010) via ${int_if} out
а пайпы выглядят как
pipe 1010 config mask src-ip 0xffffffff bw 10mbit/s
pipe 1011 config mask dst-ip 0xffffffff bw 10mbit/s
pipe 1012 config mask src-ip 0xffffffff bw 128kbit/s
pipe 1013 config mask dst-ip 0xffffffff bw 32kbit/s
после чего в linkupdown или в ipn enable достаточно просто включить/убрать адрес из соответствующей таблицы. Это также должно бы уменьшить нагрузку на ядро.
Далее. racct мы выключаем нафиг. Вместо этого прописываем каждому dv-логину статический IP (начало пула+uid, самое то), вешаем на непиринговый траффик ipacct, и вуаля, осталось только разобраться, как работает учет траффика. Соответственно, как только баланс уходит в ноль, мы просто вынимаем адрес из таблицы, не заботясь о том, висит он на vpn или на ipn. Порвать vpn тоже можно, если не лень. Пока - лень.