BiTel

Возможно ли в командах шлюза использовать один из параметров в договоре?

Цель такова:

По ряду технических причин нам необходимо клиенту (компании) выделять реальный IP, но иметь разбивку по каждому клиенту.
Показалось наиболее удобным следующая механика - в модуле IPN указывать нереальные IP адреса и тарифицировать клиента именно по ним.
А затем просто натить их всех в один реальный, указанный в договоре.
Возможна ли подобная механика?
Может быть существует иной способ решения данной проблемы.

не совсем понятно ..Вы хотите тарифицировать серые адреса, а командах шлюза использовать реальный адрес и его хотите запомнить в параметре договора ? .. Вы же может добавить реальны адрес как обычный адрес, только не добавлять привязку для этого адреса чтобы он тарифицировался, это адрес добавить на шлюз(а серые не добавлять) ..Т.е добавляете те адера на шлюз, которые должны попасть в команды .. Если я чего-то не понимаю, то покажите пример команд и какие адреса

У нас аналогичная проблема.
На одном интерфейсе у шлюза клиент имеет серые адреса, на другом (после ната) реальные и для каждого клиента свои. Тарификация происходит по серым IP.

Сейчас мы делаем так:
в биллинге просто указаны серые IP и управление клииентом происходит на том же интерфейсе, а нат для каждого клиента прописывается руками.
Это не удобно, да и учет реальных IP приходится вести отдельно.
Если бы можно было бы это автоматизировать в манаде, то было бы проще.
Например, в модуле IPN как-то "выделять" реальные IP (скажем каким-то признаком), или как у автора выше реальные IP указывать в договоре.
Последний вариант менее удобен, так как в этом случае учет все равно придется вести в ручную.

Так что вопрос тот же:

Реализуема ли эта схема?

Так реализуема данная схема?

Как Вы просили, привожу вариант команд шлюза (не самый удобный) который бы ХОТЕЛОСЬ иметь:

[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>

Может быть это реализуемо с помощью скрипта?
Приведите, пожалуйста какой нибудь вариант этой реализации.

Берем скрипт:
http://wiki.bgbilling.ru/index.php/%D0% ... _BeanShell

меняем его ..обращаемся к парметрам догвора (2-ый) и ко всем чему надо.

А могли бы все-таки как-то пояснить текст скрипта.
Правильно ли я понимаю:
Создания правила на основании "команд шлюза" происходит в
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? Не констатация существования функции, а хотя бы краткое ее описание?

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. каждый из относится к конретному договору на шлюзе . Если вы открываете/закрваете шлюз из клиента биллинга, то это список состоит всего из одного элеменента.. Если это делает задача проверки шлюзов, то в это списко помещаются все договора на даннном конретном шлюзе и шлюз должен пробежаться по ним всем




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


нет.. подробной документации нет ..