Jump to content
Калькуляторы

utm5 правильная настройка правил шейпера

Используется utm5, все примитивно, добавили пользователя в систему, добавили ему тарифную связку, в правилах браундмаера созданы правила которые смотрят на id тарифа и добавляют связку.

В скрипт паредаются следующие параметры:

/scripts/05addshaper.sh UID ULOGIN UIP/UBITS 20480 OPTICAL "UGROUP"

Как бы вопросов нету, работало...

Сам скрипт:

 

#!/bin/bash

# Параметры скрипта
ID=$1
LOGIN=$2
IP=$3
SPD=$4
TYPE=$5
GROUP=$6

let mark=${ID}+50
let mark2=${mark}+${MAXUSERS}

if [ ! -f /var/lib/shaper/${LOGIN} ]
then
   /sbin/tc class add dev $INTIF parent 1:1 classid 1:$mark htb rate ${SPD1}kbit ceil ${SPD2}kbit burst 40k
   /sbin/tc filter add dev $INTIF parent 1:0 protocol ip prio 5 handle $mark fw classid 1:$mark
   /sbin/tc qdisc add dev $INTIF parent 1:$mark handle $mark: sfq perturb 10
   sleep 0.1
   /sbin/tc class add dev $EXTIF parent 1:1 classid 1:$mark2 htb rate ${SPD3}kbit ceil ${SPD4}kbit burst 40k
   /sbin/tc filter add dev $EXTIF parent 1:0 protocol ip prio 5 handle $mark2 fw classid 1:$mark2
   /sbin/tc qdisc add dev $EXTIF parent 1:$mark2 handle $mark2: sfq perturb 10
   echo  "$TYPE $mark $mark2 $SPD1 $SPD2 $SPD3 $SPD4"  > /var/lib/shaper/${LOGIN}
   sleep 0.1
fi

/sbin/iptables -t mangle -A FORWARD -d $IP -j MARK --set-mark $mark
/sbin/iptables -t mangle -A FORWARD -s $IP -j MARK --set-mark $mark2

 

По этогу все это добавляется и работает.

Но теперь появился клиент, которому надо сделать в билинге под одной учеткой, 5 тарифных связок с разными настройками.

Если посмотреть, то в скрипт передается: ID=$1

И согласно этому ID формируется $mark, но в данном случае у всех тарифных связок будет один $mark ведь это одна учетка, как бы выкрутится? ведь получается и маркировка будет однотипной и правила корректно работать не будут.

Смотрю в этом случае на поле

тарифные связки: id связки, оно вроде как уникально получается в пределах одной связки, неужели прийдеться все таки драть его через sql код и подставлять, и тогда уже на базе него прыгать дальше?

 

не сильно конечно хотелось бы, ведь доп нагрузка на базу, она конечно маленькая совсем, но может где-то упускаю какую-то логику? или правила корявенько написаны.

Share this post


Link to post
Share on other sites

Как вариант, в качестве $1 передавать не ID клиента, а SLINK_ID, он уникальный для каждой подключенной услуги.

Share this post


Link to post
Share on other sites

Да, действительно, пробовал ведь, но не туда походу смотрел. Сегодня поправлю и проверим что получится.

Share this post


Link to post
Share on other sites

И все таки тут какая-то проблема, slink_id используется везде один и тот же.

 

?Debug : Mar 14 10:18:01 FW@127.0.0.1: Sending [/scripts/05addshaper.sh 198 283  user1057_p3 212.6.7.14/32 MANUAL OPTICAL "1105"]
?Debug : Mar 14 10:18:01 FW@127.0.0.1: Sending [/scripts/05addshaper.sh 198 283  user1057_p4 212.6.7.15/32 MANUAL OPTICAL "1105"]
?Debug : Mar 14 10:18:01 FW@127.0.0.1: Sending [/scripts/05addshaper.sh 198 283  user1057_p5 212.6.7.16/32 MANUAL OPTICAL "1105"]

 

А вот что в debug.log

Первый это ID, а вот потом идет SLINK_ID, но как вижно у всех 3-х записей он одинаковый.

Такое чувство что к базе идет запрос который возвращает одно и тоже для всех записей.

post-59340-027229000 1331717400_thumb.jpg

post-59340-099772200 1331717510_thumb.jpg

Share this post


Link to post
Share on other sites

А у вас точно логины с адресами 212.6.7.14-16 относятся к разным сервисным связкам? Просто мне видится, что к связке 283 привязано 3 логина user1057_p3-p5.

 

Не сочтите за наглость, покажите еще скрин окна Сервисные связки->Передача трафика с id:283->Редактирование

Share this post


Link to post
Share on other sites

Да, 5 сервисных связок, у каждой свой тариф и все такое.

Ну не мог же ошибиться блин.

post-59340-046487500 1331723804_thumb.jpg

Edited by Megas

Share this post


Link to post
Share on other sites

По ходу это бага UTM, даже на скине видно, что ID у связок разные.

Share this post


Link to post
Share on other sites

Отлично, теперь рисуем костыль с запросом в базу. обидно блин.

Share this post


Link to post
Share on other sites

У меня вообще шейпер через прямой опрос таблицы dynashape_data реализован. Скрипт по крону запускается. На мой взгляд, так работает надежнее, чем через rfw.

Share this post


Link to post
Share on other sites

А как реализуете, если допустим это юрик и у него скорость договорная?

плодить еще один тариф не кайфно, по этому сделал manual и выгружаю это через правила фаервола, а в самом скрипте уже пишу какие скоростя стаивть, но понимаю это ручная работа и так не должно быть.

Share this post


Link to post
Share on other sites

Будете смеяться, но таки через создание персонального ТП. Как результат: все прозрачно, менеджеры не вникают в тайные знания шейпинга, смена скорости производится через одну точку входа и все ее видят. А не так "написано 2, но у ИванИваныча тут будет 6".

Share this post


Link to post
Share on other sites

Дамс, думал решу задачу на раз два, и понял... засада...

в общем суть вот в чем:

есть данные в базе

ip_groups.ip_groups_id=300

ip_groups.uname=usertet02

под это дело надо выловить id тарифной связки.

хранится он account_tariff_link и дублируется в таблицу service_link.tariff_link_id.

в упор не пойму как перевязать это все вместе чтобы получить нужный id

Share this post


Link to post
Share on other sites

Можно отолкнуться вот от такого ужаса:

select
   service_links.account_id,
   users.login,
   dynashape_data.direction,
   dynashape_data.curr_limit,
   inet_ntoa(ip_groups.ip),
   inet_ntoa(ip_groups.mask),
   account_tariff_link.tariff_id
from
   dynashape_data,
   service_links,
   ip_groups,
   iptraffic_service_links,
   account_tariff_link,
   tariffs_services_link,
   users
where
       dynashape_data.slink_id=service_links.id
   and iptraffic_service_links.id=service_links.id
   and iptraffic_service_links.ip_group_id=ip_groups.ip_group_id
   and iptraffic_service_links.is_deleted=0
   and service_links.account_id=account_tariff_link.account_id
   and service_links.user_id=users.id
   and service_links.service_id=tariffs_services_link.service_id
   and service_links.is_deleted=0
   and service_links.tariff_link_id!=0
   and tariffs_services_link.tariff_id=account_tariff_link.tariff_id
   and tariffs_services_link.is_deleted=0
   and ip_groups.is_deleted=0
   and account_tariff_link.is_deleted=0
   and users.is_deleted=0
order by 1,5,3

 

PS: у меня база на PG, так что на мыскле возможно будет выглядеть иначе.

Edited by taf_321

Share this post


Link to post
Share on other sites

SELECT ig.uname,
      inet_ntoa(4294967295 & ip) AS IP,
      isl.id as isserlin_id,
      isl.ip_group_id,
      sl.id,
      sl.tariff_link_id
FROM ip_groups ig,
    iptraffic_service_links isl,
    service_links sl
WHERE inet_ntoa(4294967295 & ip) LIKE '21.6.5.3' and
     ig.is_deleted = 0 and
     ig.uname LIKE 'use157_p1' and
     ig.ip_group_id = isl.ip_group_id and
     isl.id = sl.id and
     sl.is_deleted = 0 and
     isl.is_deleted = 0

 

Подозреваю что как-то так будет это выглядеть

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this