PolicyBasedEngine

Обработчик PolicyBasedEngine ("основанное на политиках") аналогичен FlatRate2, кроме того, что его параметры задаются в конфигурационном файле, а политики учета по направлениям, протоколам и прочему - настраиваемы.

Единственный параметр, который надо указать в свойствах тарифного плана, в окне "Другие настройки...", это путь до файла конфигурации относительно каталога jserver/db/, или абсолютный путь - по умолчанию это pbe.cfg.

Рассмотрим дистрибутивный конфигурационный файл:

# пустые строки, а также строки (все что после символа) # - комментарии
# наличие и порядок фигурных скобок { и } - важны
# для всех элементов формат одинаков:
# имя_элемента метка {
#  параметры_элемента
# }
# при этом метка - это номер или строковое значение, на которое ссылаются в дальнейшем другие элементы
# исключение - элементы типа rule, там метки - только числа, порядковые номера правил.

# оператор include позволяет вставлять "общие" для разных тарифных планов элементы
# конфигурации, такие как правила condition (условия)
include defaultconditions.cfg

# определяет файл с префиксами подсетей (см. подробности)
prefix-file russian-nets {
	path: russian-subnets.txt
	reload: 60 # in minutes
}

# определяет условие совпадения. идентификатор условия - all_rus_ip, он будет использоваться
# далее в ссылках из правил
condition all_rus_ip { # под это условие попадает весь IP трафик
	type: traffic
	protocol: ip
	srcdst: any
	source: any # 1.224.36.4/18  or ip_addr, ip_subnet/maskbits, prefix-file russian-nets
	destination: any # 5.6.7.8/31
	port: any
	src_port: any
	dst_port: any
	ds-type: any
	ds-tag: any
}

# определяет то, как будет учитываться трафик, правило учета имеет здесь идентификатор 1
#  - будет использовано далее в правилах
accounting 1 {
	multiplier: megabyte # мультипликатор
	name: All IP traffic # имя, которое будет отображаться в поле Props окна репортинга
	direction input { # входящий
		tag: traffic-in # метка в базе данных
		rate: 10 # цена за входящий
	}
	direction output { # исходящий
		tag: traffic-out
		rate: 10
	}
}

accounting web_acct { # веб-трафик у нас бесплатно
	multiplier: megabyte
	name: All WEB traffic
	direction input {
		tag: web-in
		rate: 0
	}
	direction output {
		tag: web-out
		rate: 0
	}
}

# собственно правила учета обрабатываются по порядковому номеру.
rule 1 {
	condition: all_rus_ip # если совпало условие (IP-адрес, порт, имя data-source, ....) [подробнее]
	accounting: 1 # вести учет по методу и тарифам, определенным в accounting 1
	filter: pass # or block
	next: continue # or stop
}

rule 2 {
	condition: 2
	accounting: web_acct
	filter: pass # or block
	next: continue # or stop
}

#
# а это содержимое файла defaultconditions.cfg, включенного из pbe.cfg

condition 2 { # только веб-трафик
	type: traffic
	protocol: tcp
	port: 80,81,8080,8888,443
}

Изменения в pbe.cfg пока требуют рестарта программы.

Механизм учета по файлам префиксов подсетей

Префиксом подсети называется запись вида X.X.X.X/YY, где X.X.X.X - номер подсети, например "212.140.10.0", а YY - сетевая маска, записанная в формате числа битов "единичка" двоичного представления маски подсети. Таким образом, запись "/0" эквивалентна сетевой маске "0.0.0.0" (все хосты диапазона IPv4), "/24" маске "255.255.255.0", а "/32" маске "255.255.255.255" (единственному хосту).

Используя файлы префиксов, можно удобно производить учет (при конструировании соответствующих правил) по трафику в сторону некоторого набора подсетей, например внутренних подсетей провайдера, где тарификация нулевая, или отличается от остальной. Типичным примером может служить разделение "российского" (или любого национального) трафика, и остального трафика. Для примера в дистрибутивном комплекте поставляются два файла со списками префиксов "географических" сетей, а именно:

• russian-subnets.txt (4719 префикса)
• ukrainean-subnets.txt (2172 префикса)

Эти файлы были сгенерированы 10 января 2011 года из базы данных RIPE по технологии, описанной в "Создание файлов префиксов национальных сетей" из дистрибутива NeTAMS 3.4. Достаточно легко самостоятельно собрать и аналогичные "региональные" списки.

Если в описании элемента политики prefix-file присутствует параметр reload (значение не важно), сервис биллинга будет периодически (раз в 30 секунд) проверять, не был ли изменен файл префиксов "извне", и если таковое произошло, он будет "на лету" переподгружен. Это полезно, если вы собираетесь регулярно (скажем, раз в неделю) пересобирать внешними скриптами файл префиксов из базы RIPE, или из того списка "своих" сетей, который предоставляет вам ваш провайдер. 

Механизм cопоставлений условий (condition) в правилах (rule)

В простейшем случае можно задать идентификатор (имя или номер) условия при составлении правила, например:

rule 1 {   
	condition: all_rus   
	...

Однако есть возможность составлять простые "составные" условия, таким образом комбинируя два условия в одно. Синтаксис команды тогда такой: