Как заставить rfw передергивать правила при переходе на новый расчетный период у клиента.
Имеем:
Клиент, Тариф-128
table 2
IP_клиента
table 3
IP_клиента
на след период клиент хочет 256
должны:
по наступлению нового расчетного периода,
удалить его из 2 и 3ей таблицы и добавить в 4, 5.
Но этого не происходит.
Это произойдет только если выключить инет в личном кабинете, а затем включить.
Передергивание всего rfw раз в сутки - не предлагать.
ipfw (yable)+rfw+ смена тарифов (анлим) по окончанию р/п.
Непонятно как это реализовать, уважаемы Rav предлагает для включения Интернета (добавления правил на включение) прописать несколько правил:Rav писал(а):Serg79 делайте проще. При включении Интернета удаляйте из всех таблиц ip-адрес.
Вкл
table 1 flush
table 1 add UIP/UBITS
Выкл
table 1 delete UIP/UBITS
... и так для всех таблиц, но как себя поведет ядро с rfw, когда я хочу добавить клиента среди расчетного периода? Проверю и отпишусь
...
firewall_path=/opt/svs/cmductl
#!/usr/bin/perl
$cmd = @ARGV[0];
# Vklyuchenie tarif 512kbit/s
if ( $cmd == 4) {
`/sbin/ipfw table 7 add $ARGV[1] 7`;
`/sbin/ipfw table 8 add $ARGV[1] 8`;
exit 0; }
# Viklyuchenie tarif 512 Kbit/s
if ( $cmd == 5) {
`/sbin/ipfw table 7 delete $ARGV[1]`;
`/sbin/ipfw table 8 delete $ARGV[1]`;
exit 0; }
Для UTM5:
Тариф-512:
Включение: 4 UIP
Выключение: 5 UIP
Только почему то не работает.
#!/usr/bin/perl
$cmd = @ARGV[0];
# Vklyuchenie tarif 512kbit/s
if ( $cmd == 4) {
`/sbin/ipfw table 7 add $ARGV[1] 7`;
`/sbin/ipfw table 8 add $ARGV[1] 8`;
exit 0; }
# Viklyuchenie tarif 512 Kbit/s
if ( $cmd == 5) {
`/sbin/ipfw table 7 delete $ARGV[1]`;
`/sbin/ipfw table 8 delete $ARGV[1]`;
exit 0; }
Для UTM5:
Тариф-512:
Включение: 4 UIP
Выключение: 5 UIP
Только почему то не работает.
Это то всё делается, а вопрос стоит почему при смене ТП по окончанию РП не передергиваются правила?Rav писал(а):Я предлагаю делать так:
ipfw table 1 delete <ip-address>
ipfw table 2 delete <ip-address>
ipfw table 3 delete <ip-address>
ipfw table 4 delete <ip-address>
и т.д.
потом идет включение...
Те например необходимо выключить безлим и включить Мбайтный тариф.
По идее rfw по окончанию РП должен выключить тариф и включить.
Тогда всё бы работало.
Те скрипт работает если вручную выключить абоненту инет и включить, а не работает именно при смене ТП по окончанию РП.
Пока передергиваю rfw раз в сутки, но это не дело.
Не вопрос, согласны и доделать - направьте на путь истинный:chepuha писал(а):Ответ звучит так "Нууууу... мы же не знали что это может понадобиться"
А вообще покупая утм стоит смириться с мыслью, что некоторый функционал тебе придеться делать самому.
Но есть несоменно плюсы - конфигурация утм предельно простая.
1. Как заставить rfw передергивать правило при окончании РП
2. Если в тарифу (к одной учетной записи) подключено 2 IP адреса, как резать скорость (например к тарифу Безлим-128, подключено 2 ИП адреса, как сделать так, чтобы не каждому ИПу давалась 128кБит/с, а на оба эти адреса давалось 128кБит/с)
3. Если к учетке привязано 2 тарифа:
Безлим 64 и Безлим 256
Как сделать чтобы одному ставилось правило 64, а другому 256?
1. rfw не заставить делать то что он не умеет, но есть два способа :
а) написать скрипт который будет его перезапускать в определенный момент. Но нужно учитывать что рфв при рестарте пушит только правила включения интернета.
b) написать скрипт который будет испольюзуя конфиг rfw делать то что нужно.
2. Не к тарифу, а к сервисной связке, - все это реализуется посредством рфв и скриптов. читайте документацию, про правила фаирвола и SLINK_ID.
3. агрегировать трафик по признаку не идентификатора пользователя, а идентификатора сервисной связки.
В целом делается это так:
Создаешь IFB (или IMQ) девайсы, на них форвардишь входящий и исходящий трафик, делаешь на них дерево ,к примеру, htb классов отражающее ваще видение приоритезации трафика и фильтрами заруливаешь трафик с нужного ип в нужный класс, который соответствует SLINK_ID.
стоит отметить следущие факты:
1. Форвардить на IFB девайс нужно ingress трафик, т.е. входящий, а следовательно если вы натите трафик на этой же машине, то трафик в IFB попадет под nated ip, и следовательно зашейпиться неправильно.
2. Наиболее сложный момент - организация синхронизации дерева классов, фильтров с биллингом, есть dynashape, но в нем нет аналога SLINK_ID для rfw, а следовательно придется все делать руками.
3. Шедулеры ( части ядра линух отвечающие за изменение логики обработки пакетов ) требуют соблюдение определенных правил для корректного перераспределения пропускной способности. Для htb и cbq основное требование заключается в том что суммарное rate всех предков класса, не должно превышать его собственного rate, что в современных реалиях невозможно, поэтому это тоже надо учитывать в логике составления дерева классов.
4. Также есть параметры влияющие на обработку трафика, которые влияют на качество работы шейпера, к примеру у htb, это quantum, burst, cburst, обычно они вычисляются вручную, но нельзя сказать что автозначения оптимальны, а в некоторых случаях они вовсе не работают.
P.S.: я убил на отладку и разработку решения для линух примерно месяц, но при этом смог получить только приемлемый результат, основное недовольство - заключается в работе щейперов, при большом кол-ве классов.
а) написать скрипт который будет его перезапускать в определенный момент. Но нужно учитывать что рфв при рестарте пушит только правила включения интернета.
b) написать скрипт который будет испольюзуя конфиг rfw делать то что нужно.
2. Не к тарифу, а к сервисной связке, - все это реализуется посредством рфв и скриптов. читайте документацию, про правила фаирвола и SLINK_ID.
3. агрегировать трафик по признаку не идентификатора пользователя, а идентификатора сервисной связки.
В целом делается это так:
Создаешь IFB (или IMQ) девайсы, на них форвардишь входящий и исходящий трафик, делаешь на них дерево ,к примеру, htb классов отражающее ваще видение приоритезации трафика и фильтрами заруливаешь трафик с нужного ип в нужный класс, который соответствует SLINK_ID.
стоит отметить следущие факты:
1. Форвардить на IFB девайс нужно ingress трафик, т.е. входящий, а следовательно если вы натите трафик на этой же машине, то трафик в IFB попадет под nated ip, и следовательно зашейпиться неправильно.
2. Наиболее сложный момент - организация синхронизации дерева классов, фильтров с биллингом, есть dynashape, но в нем нет аналога SLINK_ID для rfw, а следовательно придется все делать руками.
3. Шедулеры ( части ядра линух отвечающие за изменение логики обработки пакетов ) требуют соблюдение определенных правил для корректного перераспределения пропускной способности. Для htb и cbq основное требование заключается в том что суммарное rate всех предков класса, не должно превышать его собственного rate, что в современных реалиях невозможно, поэтому это тоже надо учитывать в логике составления дерева классов.
4. Также есть параметры влияющие на обработку трафика, которые влияют на качество работы шейпера, к примеру у htb, это quantum, burst, cburst, обычно они вычисляются вручную, но нельзя сказать что автозначения оптимальны, а в некоторых случаях они вовсе не работают.
P.S.: я убил на отладку и разработку решения для линух примерно месяц, но при этом смог получить только приемлемый результат, основное недовольство - заключается в работе щейперов, при большом кол-ве классов.