forum.bitel.ru http://forum.bitel.ru/ |
|
Использование параметров договора в командах шлюза manad http://forum.bitel.ru/viewtopic.php?f=7&t=1939 |
Страница 1 из 1 |
Автор: | Fazlitdin [ 23 фев 2009, 17:48 ] |
Заголовок сообщения: | Использование параметров договора в командах шлюза manad |
Возможно ли в командах шлюза использовать один из параметров в договоре? Цель такова: По ряду технических причин нам необходимо клиенту (компании) выделять реальный IP, но иметь разбивку по каждому клиенту. Показалось наиболее удобным следующая механика - в модуле IPN указывать нереальные IP адреса и тарифицировать клиента именно по ним. А затем просто натить их всех в один реальный, указанный в договоре. Возможна ли подобная механика? Может быть существует иной способ решения данной проблемы. |
Автор: | stark [ 24 фев 2009, 14:27 ] |
Заголовок сообщения: | |
не совсем понятно ..Вы хотите тарифицировать серые адреса, а командах шлюза использовать реальный адрес и его хотите запомнить в параметре договора ? .. Вы же может добавить реальны адрес как обычный адрес, только не добавлять привязку для этого адреса чтобы он тарифицировался, это адрес добавить на шлюз(а серые не добавлять) ..Т.е добавляете те адера на шлюз, которые должны попасть в команды .. Если я чего-то не понимаю, то покажите пример команд и какие адреса |
Автор: | Mike [ 24 фев 2009, 15:43 ] |
Заголовок сообщения: | |
У нас аналогичная проблема. На одном интерфейсе у шлюза клиент имеет серые адреса, на другом (после ната) реальные и для каждого клиента свои. Тарификация происходит по серым IP. Сейчас мы делаем так: в биллинге просто указаны серые IP и управление клииентом происходит на том же интерфейсе, а нат для каждого клиента прописывается руками. Это не удобно, да и учет реальных IP приходится вести отдельно. Если бы можно было бы это автоматизировать в манаде, то было бы проще. Например, в модуле IPN как-то "выделять" реальные IP (скажем каким-то признаком), или как у автора выше реальные IP указывать в договоре. Последний вариант менее удобен, так как в этом случае учет все равно придется вести в ручную. Так что вопрос тот же: Реализуема ли эта схема? |
Автор: | Mike [ 02 мар 2009, 14:32 ] |
Заголовок сообщения: | |
Так реализуема данная схема? |
Автор: | Mike [ 04 мар 2009, 18:37 ] |
Заголовок сообщения: | |
Как Вы просили, привожу вариант команд шлюза (не самый удобный) который бы ХОТЕЛОСЬ иметь: [DEFAULT] [OPEN] # Создается цепочка rule[N1] в таблице NAT iptables -N rule[N1] -t nat # В цепочку rule записывается правило натинга на реальный адрес, # значение реального ip записано в качестве параметра в договоре # код параметра 20 iptables -A rule[N1] -t nat -j SNAT --to-source {param(20)} <LOOP> iptables -I bgbill -s {A} -j RETURN iptables -I bgbill -d {A} -j RETURN # В цепочку bgnat (цепочка для биллинга в POSTROUTING) # вставляется переход для серых адресов {A} на правило rule[N1] iptables -I bgnat -t nat -o ! vlan20 -s {A} -m policy --dir out --pol none -j rule[N1] </LOOP> /sbin/tc class add dev vlan20 parent 1:0 classid 1:[N2] htb rate 512kbit ceil 512kbit burst 4k prio 1 /sbin/tc qdisc add dev vlan20 parent 1:[N1] handle [N2]: sfq perturb 10 quantum 1500 <LOOP> /sbin/tc filter add dev vlan20 parent 1:0 protocol ip prio [N2] u32 match ip dst {A} flowid 1:[N2] </LOOP> [/OPEN] [CLOSE] <LOOP> iptables -D bgbill -s {A} -j RETURN iptables -D bgbill -d {A} -j RETURN iptables -D bgnat -t nat -o ! vlan20 -s {A} -m policy --dir out --pol none -j rule[N1] </LOOP> # Удаляется цепочка rule[N1] в таблице NAT iptables -F rule[N1] -t nat iptables -X rule[N1] -t nat /sbin/tc filter del dev vlan20 parent 1:0 protocol ip prio [N2] /sbin/tc class del dev vlan20 parent 1:0 classid 1:[N2] htb rate 512kbit ceil 512kbit burst 4k prio 1 [/CLOSE] [/DEFAULT] Возможно ли реализовать нечто подобное? Конечно, существенно удобнее было бы использовать одно из IP, указанных в адресах (можно вести их аудит). Тогда команды шлюза могли бы выглядить например так: <LOOP> iptables -I bgbill -s {A} -j RETURN iptables -I bgbill -d {A} -j RETURN # Здесь commet - это коментарий, указанный к ip-диапазону if (comment = 'RealIP') iptables -A rule[N1] -t nat -j SNAT --to-source {A} iptables -I bgnat -t nat -o ! vlan20 -s {A} -m policy --dir out --pol none -j rule[N1] </LOOP> Может быть это реализуемо с помощью скрипта? Приведите, пожалуйста какой нибудь вариант этой реализации. |
Автор: | stark [ 05 мар 2009, 14:00 ] |
Заголовок сообщения: | |
Mike писал(а): Может быть это реализуемо с помощью скрипта? Приведите, пожалуйста какой нибудь вариант этой реализации. Берем скрипт: http://wiki.bgbilling.ru/index.php/%D0% ... _BeanShell меняем его ..обращаемся к парметрам догвора (2-ый) и ко всем чему надо. |
Автор: | Mike [ 10 мар 2009, 19:27 ] |
Заголовок сообщения: | |
А могли бы все-таки как-то пояснить текст скрипта. Правильно ли я понимаю: Создания правила на основании "команд шлюза" происходит в private generateRule( status ) {...}? ruleText = ManadUtils.getRule( status.gateType, status.ruleType ) создает набор команд для шлюза с "типами правил", при этом status.gateType - сам тип шлюза; status.ruleType - тип правила для данного шлюза; ruleText - набор команд со вставленными "переменными"? Это берется из договора или из шлюза? В свою очередь rule = ManadUtils.generateRuleNew( ruleText, status.rule.getRuleText(), null, status.ruleType ) - создает непосредственно правило на основании команд? При этом, ruleText - это набор команд со вставленными "переменными"; status.rule.getRuleText() - список ip-адресов из договора? третий параметр null, каков его смысл? status.ruleType - опять тип правила? rule - это уже непосредственно правило для шлюза. И как же можно изменить принцип порождения правил, если все находится в generateRuleNew? А как увидеть порожденное правило в договоре? Пожалуйста, покажите какой-нибудь, пусть очень простой, пример порождения нового правила. Кстати, а существует документация по API? Не констатация существования функции, а хотя бы краткое ее описание? |
Автор: | stark [ 11 мар 2009, 21:27 ] |
Заголовок сообщения: | |
Mike писал(а): А могли бы все-таки как-то пояснить текст скрипта. Правильно ли я понимаю: Создания правила на основании "команд шлюза" происходит в private generateRule( status ) {...}? ruleText = ManadUtils.getRule( status.gateType, status.ruleType ) создает набор команд для шлюза с "типами правил", при этом status.gateType - сам тип шлюза; status.ruleType - тип правила для данного шлюза; ruleText - набор команд со вставленными "переменными"? Это берется из договора или из шлюза? ruleText = ManadUtils.getRule( status.gateType, status.ruleType ); это текст команд из конфига типа шлюза ..это то что в теге DEFAULT или RULE .. rule = ManadUtils.generateRuleNew( ruleText, status.rule.getRuleText(), null, status.ruleType ); Это уже обработка правил ..Т.е конечный результат.. Правила всех шлюзов обрабатываются по правилам шлюза Manad + плюс некторые дополнения . формирование этих правил описано тут: http://bgbilling.ru/v4.5/doc/ch09s11s06.html#d0e11508 statusList - состоит из объектов типа bitel.billing.server.ipn.UserStatus. каждый из относится к конретному договору на шлюзе . Если вы открываете/закрваете шлюз из клиента биллинга, то это список состоит всего из одного элеменента.. Если это делает задача проверки шлюзов, то в это списко помещаются все договора на даннном конретном шлюзе и шлюз должен пробежаться по ним всем Mike писал(а): И как же можно изменить принцип порождения правил, если все находится в generateRuleNew? А как увидеть порожденное правило в договоре? Пожалуйста, покажите какой-нибудь, пусть очень простой, пример порождения нового правила. Принцип описан по ссылке, предствленной выше . Можете либо использовать его либо нет..Можете написать эту функцию сами под свои правила Mike писал(а): Кстати, а существует документация по API? Не констатация существования функции, а хотя бы краткое ее описание?
нет.. подробной документации нет .. |
Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |